love
love copied to clipboard
love2d
love.filesystem.setCRequirePath doesn't work under Linux
I've made a minimum reproducible example:
requirePathTest.zip
main.lua
local https
local os = love.system.getOS()
if os == "Windows" then
love.filesystem.setCRequirePath("windows/??")
https = require("https")
elseif os == "Linux" then
love.filesystem.setCRequirePath("linux/??")
https = require("https")
else
print("os is not windows, not loading https")
end
print(https)
And then have the https.dll under the folder windows and the https.so under the folder linux. You can probably use empty files, if you don't want to download the zip. Just make sure you get the right error (not found).
This code works on windows but not on linux.
If you move the https.so in root dir, it will work, even though we've set the requireCPath to a subfolder.
Error
main.lua:8: module 'https' not found:
no field package.preload['https']
no 'https' in LOVE game directories.
no file 'https' in LOVE paths.
no file './https.lua'
no file '/usr/share/luajit-2.1.0-beta3/https.lua'
no file '/usr/local/share/lua/5.1/https.lua'
no file '/usr/local/share/lua/5.1/https/init.lua'
no file '/usr/share/lua/5.1/https.lua'
no file '/usr/share/lua/5.1/https/init.lua'
no file './https.so'
no file '/usr/local/lib/lua/5.1/https.so'
no file '/usr/lib/x86_64-linux-gnu/lua/5.1/https.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
Traceback
[C]: in function 'require'
main.lua:8: in main chunk
[C]: in function 'require'
[C]: in function 'xpcall'
[C]: in function 'xpcall'
Love2D version: 11.3 and 11.5 (probably 11.4 as well)
I cannot reproduce this in WSL2 running Debian 12.
Can you try if loading the https.so standalone using LuaJIT works?
I can reproduce this in WSL1 running Ubuntu 20. The original issue was produced on a native Ubuntu machine.
I can load the https.so if I place it in root dir with love2d, so there's no point in testing LuaJIT specifically.
(I assume LuaJIT doesn't have setCRequirePath)
Place breakpoint in this line and see what is filepath and the resulting handle.
https://github.com/love2d/love/blob/11.5/src/modules/filesystem/wrap_Filesystem.cpp#L836
Again, can't reproduce it using 11.5 AppImage in Debian 12 in WSL2.
I don't have my build toolchain set up. Best I can do is for you to provide me with a custom build for linux with that variable printed in console,and I'll test it in January (I'm not available for the rest of the month)
Keep in mind operating systems cannot directly load dll / .so files that are inside a zip (or .love file). You can copy them to the save directory in that situation.
They are not in a zip/love in my case. Using them straight from source files and opening the game using lovec .
Does it work if you specify the folder name when running the game instead of using .?
Some further development, I can also reproduce this on a different Windows (10) machine, so it seems it's not related to the OS on first glance.
@slime73 On windows at least, it doesn't make a difference using the folder name.
If the Windows 10 machine happen not to have VS2022 redistributable installed, that explains everything. Currently our CI compiles lua-https using VS2022 runtime.
It has love 11.5 installed, shouldn't that be enough? It's not mentioned in the wiki that you need VS2022 redistributable installed to use setCRequirePath. Also if I used love 10, what version of the redistributable would I need? 2017?
And yes, it most likely it doesn't have it as it's a clean install of Windows.
Downloaded VS 2015-2022 redist and now it works. Is it a similar issue for linux as well?
LOVE 11.5 uses VS2013 runtime compiled through AppVeyor. GitHub Actions only provides VS2019 as their oldest toolchain. In Linux, it's likely that your glibc is too old which can only be solved by recompiling lua-https yourself or updating your distro.
Why is the error "module not found" and not something else? How does an outdated toolchain make a file invisible to love?
Because SDL_LoadObject (which LOVE uses for its C loader) doesn't provide neat way to tell if the file doesn't exist or fails to load.
Makes sense. Would you consider doing SDL_GetError (with SDL_ClearError before doing SDL_LoadObject), to get more info or just leave it as is?
The dll load function (SDL_LoadObject in this case) is called for every viable extension (e.g. both .dylib and .so on macOS) and for every search path specified in setCRequirePath. That'd be a lot of error messages for you to sort through - most of them useless information - if it dumped them all out.
Also keep in mind Lua will run the dll loader function even for regular lua files, so it would dump "failed to load dll at [path]" a bunch of times for regular Lua files.
If Windows needs VS2022 redistributable, what would be the linux equivalent for this requirement?
love for windows is bundled with the C/C++ redistributable DLLs that it needs to run on its target platforms, it doesn't need a separate download. For example the official love 11.5 downloads for Windows include VS2013's msvcp120.dll and msvcr120.dll, since it's built with VS2013.
The love appimage is similarly self-contained, it has all the C/C++ library dependencies it needs in order to run on target systems down to the minimum supported one, inside the AppImage container.
On the other hand if you're using someone's build of love from a package manager on Linux, usually it's not drop-in runnable on other systems because it might depend on libraries that are elsewhere on your computer. Similarly if you're using an unofficial or otherwise custom packaged build on Linux you'll need to make sure it's runnable where you want on your own.
If it's glibc issue then there's no way other than updating your distro.
Running ldd https.so should show any dependency errors that cause https.so to not be loaded.
At long last, since this is Linux distribution issue trying to load shared library compiled for newer glibc than the user Linux distro, this in turns a system configuration issue.