Hello, Current luarocks doesn't set the right LUA_LIBDIR at installation. With the emerged luarocks, with the default configuration, I got : --------------------------------------- $ luarocks ... LuaRocks 3.7.0, the Lua package manager ... Configuration: Lua: Version : 5.3 Interpreter: /usr/bin/lua5.3 (ok) LUA_DIR : /usr (ok) LUA_BINDIR : /usr/bin (ok) LUA_INCDIR : /usr/include/lua5.3 (ok) LUA_LIBDIR : /usr/lib64/lua/5.3 (not found) **************************************** Use the command luarocks config variables.LUA_LIBDIR <dir> to fix the location **************************************** Configuration files: System : /etc/luarocks/config-5.3.lua (ok) User : /root/.luarocks/config-5.3.lua (ok) ... --------------------------------------- So it's thinking LUA_LIBDIR has to be /usr/lib64/lua/5.3 but can't find it (even obviously, it is existing. So, I trying to install it from source, and I got : --------------------------------------- Configuration: Lua: Version : 5.3 Interpreter: /usr/bin/lua5.3 (ok) LUA_DIR : /usr (ok) LUA_BINDIR : /usr/bin (ok) LUA_INCDIR : /usr/include/lua5.3 (ok) LUA_LIBDIR : /usr/lib64 (ok) Configuration files: System : /usr/local/etc/luarocks/config-5.3.lua (not found) User : /root/.luarocks/config-5.3.lua (not found) Project : /tmp/t/luarocks-3.7.0/.luarocks/config-5.3.lua (ok) Rocks trees in use: /tmp/t/luarocks-3.7.0/lua_modules ("project") /root/.luarocks ("user") /usr/local ("system") --------------------------------------- So, back to emerged luarocks : --------------------------------------- # luarocks config variables.LUA_LIBDIR /usr/lib64 Wrote variables.LUA_LIBDIR = "/usr/lib64" to /root/.luarocks/config-5.3.lua --------------------------------------- and then, it's working :) --------------------------------------- Configuration: Lua: Version : 5.3 Interpreter: /usr/bin/lua5.3 (ok) LUA_DIR : /usr (ok) LUA_BINDIR : /usr/bin (ok) LUA_INCDIR : /usr/include/lua5.3 (ok) LUA_LIBDIR : /usr/lib64 (ok) Configuration files: System : /etc/luarocks/config-5.3.lua (ok) User : /root/.luarocks/config-5.3.lua (ok) Project : /tmp/t/luarocks-3.7.0/./.luarocks/config-5.3.lua (ok) Rocks trees in use: /tmp/t/luarocks-3.7.0/./lua_modules ("project") /root/.luarocks ("user") /usr/local ("system") --------------------------------------- So, as a conclusion, then problem : LUA_LIBDIR is not set to the right location at installation phase. Thanks Laurent
Despite this configuration corrected, it still installing in the wrong directory. As example, if I'm trying to install : ---- # luarocks install luafilesystem Installing https://luarocks.org/luafilesystem-1.8.0-1.src.rock luafilesystem 1.8.0-1 depends on lua >= 5.1 (5.3-1 provided by VM) gcc -O2 -fPIC -I/usr/include/lua5.3 -c src/lfs.c -o src/lfs.o gcc -shared -o lfs.so src/lfs.o luafilesystem 1.8.0-1 is now installed in /usr/share/lua/5.3 (license: MIT/X11) ---- but Lua can't find it as looking in /usr/lib64/lua/5.3/ ---- # /usr/local/Domestik/Client/dmkcheckd /usr/bin/lua: /usr/local/Domestik/Client/dmkcheckd:37: module 'lfs' not found: no field package.preload['lfs'] no file '/usr/share/lua/5.3/lfs.lua' no file '/usr/share/lua/5.3/lfs/init.lua' no file '/usr/lib64/lua/5.3/lfs.lua' no file '/usr/lib64/lua/5.3/lfs/init.lua' no file './lfs.lua' no file './lfs/init.lua' no file '/usr/lib64/lua/5.3/lfs.so' no file '/usr/lib64/lua/5.3/loadall.so' no file './lfs.so' ---- As a workaround, I created a symlink --- # ln -s /usr/share/lua/5.3/lib/lua/5.3/ /usr/lib64/lua/ --- but it's obviously as not as clean as it should be :)
Another test ... and I found out the problem : luarocks is always prepending a /usr/share/lua/5.3/ whereas Lua does't :( So : --- # luarocks install luaposix ... luaposix 35.0-1 is now installed in /usr/share/lua/5.3 (license: MIT/X11) --- and --- # /usr/local/Domestik/Client/dmkcheckd /usr/bin/lua: /usr/local/Domestik/Client/dmkcheckd:67: module 'posix' not found: no field package.preload['posix'] no file '/usr/share/lua/5.3/posix.lua' no file '/usr/share/lua/5.3/posix/init.lua' no file '/usr/lib64/lua/5.3/posix.lua' no file '/usr/lib64/lua/5.3/posix/init.lua' no file './posix.lua' no file './posix/init.lua' no file '/usr/local/Domestik/Client/posix.lua' no file '/usr/lib64/lua/5.3/posix.so' no file '/usr/lib64/lua/5.3/loadall.so' no file './posix.so' --- because --- # find /usr/share/lua -type d -name 'posix*' /usr/share/lua/5.3/lib/lua/5.3/posix /usr/share/lua/5.3/share/lua/5.3/posix ---
stable 3.5.0 seems to behave the same, not that I'm familiar with it (maintainer should know better), but I do express concerns over running this as root rather than user with --local.
I'm running it as root because I need it system-wide : in addition to desktop application running under my own user, I made also some daemons for monitoring purposes running as other unprivilegied user.
Hm, I can't really reproduce? I did give a try and emerged luarocks: LUA_SINGLE_TARGET="lua5-1" emerge -av1 luarocks System Lua on CLI is set to 5.4: $ lua -v Lua 5.4.2 Copyright (C) 1994-2020 Lua.org, PUC-Rio Running 'luarocks install luaposix' emerges for lua5.1? luaposix 35.0-1 is now installed in /usr/share/lua/5.1 (license: MIT/X11) ---------- Btw, we have luaposix and all deps in tree, so you don't need to use luarocks for that.
Yes, I got the same message, but the files are physically installed in sub directory tree as you can see in my comment #2 (https://bugs.gentoo.org/793758#c2) And this sub directory tree is not expected by Lua. Another test : the output of "luarocks path" is different compared to Lua is set by default. ---------- PSet ~ # lua Lua 5.3.6 Copyright (C) 1994-2020 Lua.org, PUC-Rio > print( package.path ) /usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua > print( package.cpath ) /usr/lib64/lua/5.3/?.so;/usr/lib64/lua/5.3/loadall.so;./?.so > PSet ~ # luarocks path export LUA_PATH='/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/lib64/lua/5.3/?.lua;/usr/lib64/lua/5.3/?/init.lua;./?.lua;./?/init.lua;/root/.luarocks/share/lua/5.3/?.lua;/root/.luarocks/share/lua/5.3/?/init.lua;/usr/share/lua/5.3/share/lua/5.3/?.lua;/usr/share/lua/5.3/share/lua/5.3/?/init.lua' export LUA_CPATH='/usr/lib64/lua/5.3/?.so;/usr/lib64/lua/5.3/loadall.so;./?.so;/root/.luarocks/lib/lua/5.3/?.so;/usr/share/lua/5.3/lib/lua/5.3/?.so' export PATH='/root/.luarocks/bin:/usr/share/lua/5.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/11/bin:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/usr/games/bin' ----------
Ah, Okay, I see, what you are up to. But I am currently not sure, if this is really, what you want. Basically I don't think, it't wrong, that luarocks install in it's own subdirectory, as otherwise this could seriously collide with other dev-lua/* packages. We can't rely, that system lua will just use luarocks pathes, so basically, you should set LUA_PATH by yourself and lua will look up into that directories. I would not be happy to let install luarocks all stuff into your system path, as it could override stuff from emerged dev-lua/* stuff. @Marecki: What do you think?
(In reply to Conrad Kostecki from comment #7) > @Marecki: What do you think? Pretty much what you have just said. We definitely do NOT want rocks to be installed in PM-managed directories.
In this case, why not adding both in embedded Lua's binary ? First packaged ones, then rocks. The problem with the current situation where setting LUA_PATH is mandatory, it's preventing usages of multiple Lua version on the same system. As example, some tools needs 53 (conky) whereas I'm still using others that are sticks with 5.1. Obviously we can cheat using local LUA_PATH in shell script, but clearly is not user friendly :) Anyway, the fact Luarocks can't find LUA_LIBDIR out of the box is a bug.
Closing here.
