Luarocks does not install into lib64 folder but lib instead

Ask Fedora Ask in English
1

Hi all,

I am a bit new to lua, so i apologize if this is some kind of “obvious” question.

I am running Fedora 37 64bits. I have installed “lua” and “luarocks” from the official repository.

I need “lua-periphery”, so I followed the instructions and installed it using:
$ sudo luarocks install lua-periphery

However, the lua script using this library complained in the require("periphery") because it could not find “periphery.so” in the “/usr/lib64” folder.

Indeed, this file had been copied to “/usr/lib” instead. Simply manually copying it to “/usr/lib64” made the script work.

I tried in a laptop running Arch Linux, and “luarocks” behaved correctly (it copied the file to “/usr/lib64”)

Do i have to do something specific for the files to be copied to the right folder?

Thank you very much for your help
Regards

2

A symbolic link could be worth a try

something like sudo ln -s /usr/liblua-5.4.so /usr/lib64/liblua-5.4.so

Should the lib be updated your link would still point to the updated lib, which isn’t the case if you copy the file.

3

Thank you very much Flo for the answer :slight_smile:
That is actually what I did after verifying copying works.

Any idea on why this is necessary? Why is it not installed into the “lib64” folder automatically?

Thanks!

4

not familiar, haven’t looked into it, maybe you find an answer here
https://src.fedoraproject.org/rpms/luarocks/blob/rawhide/f/luarocks.spec

or, @ferdnyc can tell.

5

Thanks Flo!

Just for the sake of clarity (sorry, I read your previous answer wrong):
luarocksitself seems to be installed fine (afaics)
They are the installed “rocks” which are not copied to /usr/lib64

This is what happens if I run a script with require("periphery") if I do not manually copy (or link) “periphery.so” file:

lua: ./release:24: module 'periphery' not found:
	no field package.preload['periphery']
	no file '/usr/share/lua/5.4/periphery.lua'
	no file '/usr/share/lua/5.4/periphery/init.lua'
	no file '/usr/lib64/lua/5.4/periphery.lua'
	no file '/usr/lib64/lua/5.4/periphery/init.lua'
	no file './periphery.lua'
	no file './periphery/init.lua'
	no file '/usr/lib64/lua/5.4/periphery.so'
	no file '/usr/lib64/lua/5.4/loadall.so'
	no file './periphery.so'

Maybe I should look into lua-periphery’s installation, but Arch Linux does this fine, that’s why I think it has something to do with luarocks itself.

1 Like
6

lib_modules_path (string) - The path where modules with native C extensions will be installed. If you are using a x86_64 *nix OS, you will probably need this line in config.lua: lib_modules_path="/lib64/lua/"..lua_version. See issue 416.

7

This seems to indicate that luarocks itself has an issue and the built in scripts that install the lua-periphery part need to be updated. Possibly a bug report would be in order?

8

Thank you very much both!!!

@augenauf Your direction has worked!!! indeed following the instruction in that issue has solved it. Thanks!

@computersavvy I will look into that too. If I see there is a problem there, I will file a bug report.

Thanks guys!

9

Or a patch that Fedora could pull in for config.lua defining the right lib dir for the rocks. After all, it’s a config issue with Lua.

10

So, it appears this is very much all my fault.

Up until luarocks 3.9.1, Fedora’s builds were in fact patching its src/luarocks/core/cfg.lua so that it would default to /usr/lib64/ as the library path on 64-bit Fedora installs.

My 3.9.1 update PR includes a note that it “dropped upstreamed patch”, and deletes that patch.

I don’t know what gave me the impression that the patch had been upstreamed, because it clearly hasn’t. (Perhaps it failed to apply to the 3.9.1 sources, and patch offered (as it is wont to do) to try reversing it, leading me to assume that it had already been applied by upstream.)

Regardless, the patch is clearly still necessary. So I’ve restored it from the commit history, and updated it to apply to the 3.9.1 sources. (It did, in fact, not apply cleanly in its original form.) As soon as my mockbuild run finishes and I can test that it fixes the issue, I’ll submit PRs adding the patch back to the luarocks.spec for rawhide, f38, and f37. Hopefully someone can get that committed and produce new builds.

Sorry about that!

1 Like
11

Submitted against rawhide, for starters. And now we wait…

1 Like
12

Thank you very much to you all!

This has been my first time here after switching back from ArchLinux and you guys give an amazing support.

Thank you very much @ferdnyc for taking the time to fix this (I hope upstream also takes the time apply it so the patch will no longer be necessary)

13

Oh, I very much doubt they will, at least not in its current form as it’s very heavy-handed. All the patch does is check for the existence of a /usr/lib64 directory, and if it finds one it sets that as the default library install path.

That’s fine enough for a local Fedora patch, but for more general use it’s incredibly fragile. Especially since /usr/lib64 is defined as (an optional) part of the Filesystem Hierarchy Standard. Even Ubuntu installs have a /usr/lib64/ directory — their libc6 package installs it — but that should most definitely not be the default install path on Debian-derived systems.

What a more-robust, correct method of determining the default path would look like, so that it could be done by the upstream code, is an open question.

At any rate, I’ve also now submitted PRs targeting the f38 and f37 branches, to make the same fix (and do an update to luarocks 3.9.2) that my previous PR applies to the rawhide branch.

Still, I’m not a maintainer of the luarocks package, and despite there being 16 subscribers besides myself, experience so far tells me that PRs in that repo don’t tend to attract much in the way of response, and certainly not quickly. So I can’t predict how soon this might be fixed.

(I neglected to mention, earlier, that I’ve also filed a bug report about the incorrect default install directory.)