In order for Gentoo Linux to properly support side-by-side installation of different versions of Lua (including LuaJIT), please migrate this package as to lua.eclass (for packages which should support multiple Lua implementations at the same time, i.e. most likely Lua modules) or lua-single.eclass (for packages which only have to support one Lua implementation at a time). For details, consult documentation of respective eclasses as well as already-migrated ebuilds in the tree. Please note that since slotted dev-lang/lua is currently masked, your migrated ebuilds should be masked as well. There is a section of package.mask, created in September 2020, which you can use for this purpose so that it will be easier in the future to unmask them all in one go. Thank you in advance for your effort!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9feed107616c754f8a2368cd770b22a28a0a6ac0 commit 9feed107616c754f8a2368cd770b22a28a0a6ac0 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-12-10 00:36:34 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-12-10 00:55:47 +0000 app-editors/neovim: migrate to lua-single.eclass Both the latest release and the live ebuild. Set LUA_COMPAT to 'lua5-{1,2} luajit' as per the upstream build scripts; builds fine against lua5.3 but I haven't reviewed the included Lua scripts for compatibility with that version and there is no test phase yet. Migration-wise, one thing worth pointing out is that upstream build scripts attempt to locate some of the Lua modules by locating a Lua interpreter on the *build* system and telling to load those modules. For now all that has been changed is that we force the use the interpreter to match the value of LUA_SINGLE_TARGET (nb. the messages like "[lua5.2] file not found" can be ignored - there is one check which expects an absolute path and by setting LUA_PRG to $ELUA instead of $LUA we can re-use this variable for dev-lua/luv detection, this is just a status message though), then again it might require further revision. Will leave this to the actual maintainers. Beyond the above, it was just having to force CMake to look for a specific Lua version (usual) as well as a tweak to dev-lua/luv detection so that it works with multi-impl installations of that package (expected). Closes: https://bugs.gentoo.org/752912 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../files/neovim-0.4.4-cmake_lua_version.patch | 11 +++ .../files/neovim-0.4.4-cmake_multiimpl_luv.patch | 11 +++ app-editors/neovim/neovim-0.4.4-r100.ebuild | 110 +++++++++++++++++++++ app-editors/neovim/neovim-9999.ebuild | 41 +++++--- profiles/package.mask | 1 + 5 files changed, 159 insertions(+), 15 deletions(-)
I have tested the latest neovim-0.4.4-r100.ebuild. The package can compile, but the compiled executable cannot run on my system (with slotted lua set up). $/usr/bin/nvim /usr/bin/nvim: error while loading shared libraries: libluv.so.1: cannot open shared object file: No such file or directory $lddtree /usr/bin/nvim nvim => /usr/bin/nvim (interpreter => /lib64/ld-linux-x86-64.so.2) libc.so.6 => /lib64/libc.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libluv.so.1 => not found libuv.so.1 => /usr/lib64/libuv.so.1 libdl.so.2 => /lib64/libdl.so.2 libpthread.so.0 => /lib64/libpthread.so.0 libmsgpackc.so.2 => /usr/lib64/libmsgpackc.so.2 libvterm.so.0 => /usr/lib64/libvterm.so.0 libtermkey.so.1 => /usr/lib64/libtermkey.so.1 libunibilium.so.4 => /usr/lib64/libunibilium.so.4 libm.so.6 => /lib64/libm.so.6 libutil.so.1 => /lib64/libutil.so.1 libluajit-5.1.so.2 => /usr/lib64/libluajit-5.1.so.2 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_s.so.1 So the rpath of libluv.so.1 is not set up correctly by the linker. This file is located at /usr/lib64/lua/5.1/. I am using LuaJIT as the single target. The workaround is to set LD_LIBRARY_PATH. Or I can use patchelf, but I didn't figure out how. I hope we can reopen this issue.
This issue is fixed with the latest commit https://gitweb.gentoo.org/repo/gentoo.git/commit/app-editors/neovim/neovim-0.4.4-r100.ebuild?id=c9635cbd84e82d8e46873c7ee5f6911dff69594f by making luv a single impl. Although this is not ideal (someone may need luv of a different lua version), it solves my current problem.
