Error when running require "lanes".configure()

[kkrime]

Getting:

Lua 5.4.6  Copyright (C) 1994-2023 Lua.org, PUC-Rio
> require "lanes".configure()
error loading module 'lanes.core' from file '/Users/iraq/.luarocks/lib/lua/5.1/lanes/core.so':
        /Users/iraq/.luarocks/lib/lua/5.1/lanes/core.so:1: unexpected symbol near '<\207>'
stack traceback:
        [C]: in ?
        [C]: in function 'require'
        /Users/iraq/.luarocks/share/lua/5.1/lanes.lua:58: in function 'lanes.configure'
        (...tail calls...)
        [C]: in ?

This is probably related;
I'm running on a m1 mac with MacOS 14.5 installed

also, for the life of me I cannot get lanes to compile when I try to compile it manually

Any help would be greatly appreciated

[benoit-germain]

I don't find the string "unexpected symbol near" anywhere in the Lua or Lanes code, so I have no idea where it comes from. That being said I see that you load a Lanes module apparently built for Lua 5.1 (based on the path where it comes from) into a Lua 5.4 VM. This is not going to end well.

As for building lanes manually, I would hope that the makefile is enough, but if there are fixes to do I can only count on external help because I don't have a mac at hand nor plan to buy one.

[stevewi-niteflyte]

This looks remarkably similar to #230. You should see the discussion there.

@benoit-germain writes:

That being said I see that you load a Lanes module apparently built for Lua 5.1 (based on the path where it comes from) into a Lua 5.4 VM. This is not going to end well.

Not true! The Makefile boilerplate for luarocks sets the destination for the lanes shared library to:

#--- Installing ---
#
# This is for LuaRocks automatic install, mainly
#
# LUA_LIBDIR and LUA_SHAREDIR are used by the .rockspec (don't change the names!)
#
DESTDIR=/usr/local
LUA_LIBDIR=$(DESTDIR)/lib/lua/5.1
LUA_SHAREDIR=$(DESTDIR)/share/lua/5.1

(probably to maintain some kind of implicit compatibility with LuaJIT). The actual shared library being built is for Lua5.4:

# Autodetect LUA
#
LUA=$(word 1,$(shell which lua5.1$(_LUAEXT)) $(shell which lua51$(_LUAEXT)) $(shell which lua$(_LUAEXT)) $(shell which luajit$(_LUAEXT)))

$(shell which lua$(_LUAEXT)) is the only expression that produces anyththing IF you do not have LuaJIT or Lua5.1 installed (which, I assume the OP does not...my guess is that s/he installed Lua5.4 with Homebrew like I did).

I'm pretty sure DESTDIR, LUA_LIBDIR & LUA_SHAREDIR all get overridden by the luarocks configuration file in force at the time of the luarocks install too.

@kkrime -- Unless you are prepared to:

• hand-build from source and debug every luarock that depends on C code you want to use in your Mac project; and/or
• do battle with the luarocks team to update their packaging so that it does The Right Thing™ on macOS;

I'd abandon this effort right now and engage a skilled dominatrix. The dominatrix will be a better value...

[benoit-germain]

The fact is, this half-luarocks support that exists in the makefile is something that very likely broke over time. I'm not the original author of all that part, because my understanding of the interactions between luarocks and the makefile is very lacking. That's why the rockpec uses the "builtin" build model, so that I let luarocks do its magic. I am a PC world guy, so for development purposes I have Visual Studio projects and solutions, because the IDE and integrated debugger are what I know and find most convenient.

Lanes should be pretty straightforward to build: point the includes and libs towards the Lua flavor you build against, compile all cpp, link everything in a DLL/so, and you should be good to go. I tried to remove as much platform-specific code as I could, but If some compilers need to be massaged to do the right thing, this has to be done by someone gifted with the knowledge and the availability of the target development environment.

Similarly, if the makefile can be improved on, I'll gladly accept the input of anyone more knowledgeable than me.