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

Most upvoted comments

In case of a non-default location, you should pass LUA_PATH=/usr/local/opt/luajit-openresty/share/luajit-2.1.0-beta3/jit/?.lua to the build environment, when compiling luvi.

But my non-default location works when luajit is invoked without setting LUA_PATH. It seems to me that we should only be doing LUA_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 of luajit -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:

CMake Error in CMakeLists.txt:
  Cannot find source file:

    /tmp/luvit--luvi-20210121-94985-vucl7x/tmp/luvit--luvi-20210121-94985-vucl7x/deps/lpeg/re.lua

The correct path to re.lua is tmp/luvit--luvi-20210121-94985-vucl7x/deps/lpeg/re.lua. Not sure why the prefix is getting doubled there. Setting

export LPEGLIB_DIR=deps/lpeg

fixes 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:

        COMMAND luajit

and see if that fixes it for you?