Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)

[Ross]

I'm trying to figure out a way to iterate through arbitrary directories. I tried Love-FML and NativeFS but both crashed with similar errors.

Love-FML crashed when requiring the module:

Code: Select all

Error: lib/love-fml/fml.lua:42: /lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_getLinkedVersion
stack traceback:
	[string "boot.lua"]:777: in function <[string "boot.lua"]:773>
	[C]: in function '__index'
	lib/love-fml/fml.lua:42: in main chunk
	[C]: in function 'require'

NativeFS required fine but crashed when I tried to call nativefs.getDirectoryItems:

Code: Select all

Error: lib/nativefs/nativefs.lua:345: /lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_getMountPoint
stack traceback:
	[string "boot.lua"]:777: in function <[string "boot.lua"]:773>
	[C]: in function '__index'
	lib/nativefs/nativefs.lua:345: in function 'withTempMount'
	lib/nativefs/nativefs.lua:357: in function 'getDirectoryItems'

So now I'm wondering if there's something missing on my system that's assumed to be there? Or if both of these libraries are only written to work on windows maybe? Has anyone used either of these libraries recently?

I'm using Löve 11.3, on Linux Mint.

Löve's arbitrary limitations on filesystem stuff really drive me nuts. Hopefully they'll be removed at some point.

[marclurr]

Looks like you're missing PhysFS, not sure the easiest way to install it, I've built it manually as part of my own projects in the past. Here is the website for it https://icculus.org/physfs/

[GVovkiv]

as marclurr pointed out, mint probably doesn't have out-of-box physfs?
i sure that any modern distro, such mint, should have in it repositores physfs package (maybe on different distro they might have different naming tho). On rpm based, there is physfs package avaiable, so maybe mint have it.
Maybe "sudo apt install physfs"?

[Ross]

OK, thanks. Well, I did try installing PhysFS (both the regular and -dev packages) through my package manager, but it didn't make any difference, same errors.

I'm a total noob when it comes to C and FFI stuff, but this line from Love-FML: `local ver = ffi.new('PHYSFS_Version[1]')` gives a cdata struct result...which seems to indicate that PhysFS does exist? [Edit:] Oh, no I guess not. That struct is just defined inside a ffi.cdef, but the actual PhysFS functions don't exist, bugger.

[GVovkiv]

Hm
1st, you probably want then go to love's github page (https://github.com/love2d/love/issues) and create new issues, maybe slime will be able to help.
2nd, i was having same kinda issue before, but with SDL in fedora. It turns out, that love expected SDL (i don't remember exact version) to be 2.0.20, but fedora's repositories only had 2.0.18, so i ended up use flatpak love (https://flathub.org/apps/details/org.love2d.love2d) until SDL was updated in fedora's repos. Maybe same issue here?
Try flatpak version, maybe it will help as workaround.

[pgimeno]

Löve includes PhysFS. If the NativeFS doesn't find a PhysFS function, it may be a bug in the library. Or it may be something in your runtime environment not anticipated by the writers of the library.

For some reason it's trying to read from /lib/x86_64-linux-gnu/libluajit-5.1.so.2 instead of from love.so; any idea why?

[Ross]

@GVovkiv: Alright. Well flatpak is wanting to download 650MB worth of dependencies first, so I'll wait until I'm a little bit more desperate to try that.

Löve includes PhysFS. If the NativeFS doesn't find a PhysFS function, it may be a bug in the library. Or it may be something in your runtime environment not anticipated by the writers of the library.

OK, that's what I thought. That the whole point in using PhysFS was that it's already included.

For some reason it's trying to read from /lib/x86_64-linux-gnu/libluajit-5.1.so.2 instead of from love.so; any idea why?

No, I don't know. Though I do wonder if the LuaJIT .so is simply the last place that it looked?
I read through the LuaJIT FFI documentation, but this was the only part that seemed somewhat relevant (but still doesn't shed any light for me):

ffi.C

This is the default C library namespace — note the uppercase 'C'. It binds to the default set of symbols or libraries on the target system. These are more or less the same as a C compiler would offer by default, without specifying extra link libraries.

On POSIX systems, this binds to symbols in the default or global namespace. This includes all exported symbols from the executable and any libraries loaded into the global namespace. This includes at least libc, libm, libdl (on Linux), libgcc (if compiled with GCC), as well as any exported symbols from the Lua/C API provided by LuaJIT itself.

On Windows systems, this binds to symbols exported from the *.exe, the lua51.dll (i.e. the Lua/C API provided by LuaJIT itself), the C runtime library LuaJIT was linked with (msvcrt*.dll), kernel32.dll, user32.dll and gdi32.dll.

[pgimeno]

Is that a Löve executable coming from a system package? Maybe the Mint package tries to use an external LuaJIT, and can't find the love.so library. You might be luckier compiling Löve from source.

Or, find where love.so is, and load that into FFI. You might need to modify NativeFS to tell it the right path.

[Ross]

OK, it seems like my Löve installation was messed up. I had installed it through my package manager, which seems to take it from the Ubuntu package database. I did not have any 'liblove.so' or 'liblove-11.3.so', etc., on my system at all, just a 'love' executable.

I tried the official AppImage and that worked. I also tried building from source and that worked, with the workaround from here (running it with: 'LD_LIBRARY_PATH=. ./love'). But then I wasn't sure where to actually put the files to install it correctly, so I used the official love-stable PPA, reinstalled Löve from that, and now it works.

Whew! Solved. Thanks everybody for your help!

[pgimeno]

Well, the question remains whether the Mint package is broken and needs to be reported. Mint users may find issues with Löve and think it's Löve's fault, and come to ask for help here. Whether you feel like digging into that is another story.

It would be interesting to know if the `love` executable (from the Mint package) is an ELF or a script. If it's an ELF, the output of `ldd "$(which love)"` should tell you where it's loading love.so from. I don't think it will be statically linked; otherwise you wouldn't be having that issue (I use it statically linked and it's fine). If it's a script, the contents would also be interesting.