luvi: Build failure with custom LuaJIT (OpenResty fork)
I’m trying to build luvi with a custom LuaJIT, which is the latest release build from the OpenResty fork. This produces the following build error:
luajit: unknown luaJIT command or jit.* modules not installed
luajitluajit: unknown luaJIT command or jit.* modules not installed
: unknown luaJIT command or jit.* modules not installed
make[2]: *** [jitted_tmp/src/lua/luvibundle.lua_luvi_generated.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [jitted_tmp/deps/lpeg/re.lua_luvi_generated.o] Error 1
make[2]: *** [jitted_tmp/src/lua/init.lua_luvi_generated.o] Error 1
luajit: unknown luaJIT command or jit.* modules not installed
make[2]: *** [jitted_tmp/src/lua/luvipath.lua_luvi_generated.o] Error 1
make[1]: *** [CMakeFiles/luvi.dir/all] Error 2
make: *** [all] Error 2
LuaJIT was built using the standard make amalg
, so I’m not sure why I’m getting this error. Setting LUA_PATH
to LuaJIT’s jit
directory as explained in https://github.com/luvit/luvi/commit/a9dc8dae2eb69d4a754a0cf5c08622d70f6b7067 didn’t help. Assistance would be appreciated.
Complete build logs: https://gist.github.com/carlocab/2a6c25344be31127f61635d8978b3720
These were generated while attempting a build in Homebrew, but I can reproduce this without Homebrew using just a make tiny
with the appropriate environment variables for set to enable building with a shared libluv. (I’m actually doing this to assist with Homebrew packaging of luvit. The latest luvi release doesn’t build on Apple Silicon.)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (15 by maintainers)
Commits related to this issue
- CMake: Make usage of LUA_PATH in LuaJITAddExecutable depend on it being set Should fix #242 — committed to squeek502/luvi by squeek502 2 years ago
- CMake: Make usage of LUA_PATH in LuaJITAddExecutable depend on it being set (#258) Should fix #242 — committed to luvit/luvi by squeek502 2 years ago
But my non-default location works when
luajit
is invoked without settingLUA_PATH
. It seems to me that we should only be doingLUA_PATH=${LUA_PATH}
when it’s already set in the environment, or else it’ll break things even for default locations. See neovim/neovim#16714.Is there any reason why we don’t want to just set
LUA_PATH
to the output ofluajit -e 'print(package.path)'
?I should also actually mention that using a shared libluv also causes errors with how
LPEGLIB_DIR
is set. Without manual intervention, I get this build error:The correct path to
re.lua
istmp/luvit--luvi-20210121-94985-vucl7x/deps/lpeg/re.lua
. Not sure why the prefix is getting doubled there. Settingfixes the problem.
Nice!
I’m not totally sure why that line has the
"LUA_PATH=${LUA_PATH}"
in it currently. Will need to investigate this more to see if it’s necessary at all.Can you try changing this line:
https://github.com/luvit/luvi/blob/1c7cb3dc71582b490c9a748522f6bdff91ff05d2/cmake/Modules/LuaJITAddExecutable.cmake#L32
to:
and see if that fixes it for you?