Very true. It would be good to get that fixed. I'd be happy to carry out my civic duty to some extent, I just don't know much about it.
With the Mint package installed that 'ldd' command does output a long list, but there's no love.so (or liblove, etc.) in it.
Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
Interesting. How big is the love executable? Is it in the few tens of kB range or more like in the tens of MB?
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
Hm, it's most likely a stripped statically linked executable, which produces that length for me with version 11.3. I'm also using a (non-stripped) static build.
I've tried the unit tests from NativeFS (https://github.com/EngineerSmith/native ... /main/test) and many failed. Here's the report:
I haven't investigated the cause, but maybe NativeFS doesn't like statically linked executables.
I've tried the unit tests from NativeFS (https://github.com/EngineerSmith/native ... /main/test) and many failed. Here's the report:
Code: Select all
Started on Wed Jul 6 21:14:43 2022
test_File_flush ... Ok
test_File_isEOF ... FAIL
main.lua:303: expected: false, actual: true
test_File_lines ... ERROR
./nativefs.lua:158: File is not opened for reading
test_File_open ... FAIL
main.lua:13: expected: true, actual: false
test_File_read ... FAIL
main.lua:313: expected: "Lorem"
actual: nil
test_File_seek ... FAIL
main.lua:363: expected: "tempor"
actual: nil
test_File_setBuffer ... Ok
test_File_tell ... FAIL
main.lua:374: expected: 172, actual: nil
test_File_write ... Ok
test_fs_append ... FAIL
main.lua:105: expected: 900, actual: "Could not open file data/append.test. Does not exist."
test_fs_createDirectory ... Ok
test_fs_getDirectoryItems ... FAIL
main.lua:142: expected: 3, actual: 1
test_fs_getDirectoryItemsInfo ... ERROR
main.lua:172: attempt to index local 'info' (a nil value)
test_fs_getDriveList ... Ok
test_fs_getInfo ... FAIL
main.lua:212: Received the not expected value: nil
test_fs_lines ... ERROR
main.lua:113: attempt to call a nil value
test_fs_load ... FAIL
main.lua:130: Received the not expected value: nil
test_fs_mount ... FAIL
main.lua:57: Received the not expected value: nil
test_fs_newFile ... Ok
test_fs_newFileData ... ERROR
main.lua:48: attempt to index local 'fd' (a nil value)
test_fs_read ... FAIL
main.lua:65: expected: 450, actual: "Could not open data/ümläüt.txt in mode r"
test_fs_remove ... Ok
test_fs_setWorkingDirectory ... Ok
test_fs_write ... ERROR
./nativefs.lua:172: attempt to index local 'data' (a nil value)
test_xxx_globalsCheck ... Ok
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
That mirror broke many tests because someone decided to replace all LF characters with CR/LF in all files (including the test data files), and there was also code added but no tests written or adapted to the changed code. The tests were ignored and they are useless now.pgimeno wrote: ↑Wed Jul 06, 2022 7:20 pm I've tried the unit tests from NativeFS (https://github.com/EngineerSmith/native ... /main/test) and many failed. Here's the report:
Yeah, the PhysFS ffi imports will only work with .so/.dll linkage.I haven't investigated the cause, but maybe NativeFS doesn't like statically linked executables.
Here's my latest local copy of the lib, with all tests still passing, including git history in case someone wants to put up a proper repo.
P.S.: In retrospect, test_fs_lines() should not use main.lua as its test corpus, because it assumes LF line endings in test/main.lua. That's a bogus assumption (line endings in code can change inadvertently when mixing OSs) that should be fixed by the potential new maintainer, if they care about tests passing.
- Attachments
-
- nativefs.zip
- (328.24 KiB) Downloaded 138 times
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
Hi grump, it's a pleasure seeing you around again. You've been missed.
Thanks for providing the repository. I have uploaded it to Codeberg at https://codeberg.org/pgimeno/nativefs
- Most tests fail unless run from inside the test directory. I did not know that and ran them from the root of the repo, causing lots of failures.
- A dynamic version of 11.3 passes all tests (in your repo, not in the clone).
- A static version of 11.3 fails many tests with one of these errors:
"../nativefs.lua:351: /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_getMountPoint"
"../nativefs.lua:248: /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_mount"
That's probably what Ross was experiencing.
- Either a dynamic or static version of 11.4 (doesn't seem to matter) passes all tests but one:
I haven't investigated the failure yet, I've got a lot on my plate at this moment.
It's a possibility that the fact that a static 11.4 build finds PhysFS, unlike 11.3, has to do with me having used cmake instead of autotools for building, but I'm not sure what I actually used for each of the builds so I can't be sure.
Thanks for providing the repository. I have uploaded it to Codeberg at https://codeberg.org/pgimeno/nativefs
I've committed a change for the test data files which will hopefully make this not an issue anymore in future, by adjusting .gitattributes and normalizing the line endings. Maybe instead of text with specific line endings, I should have made the files binary, but well, it was hard to tell which was the correct decision.grump wrote: ↑Sat Jul 09, 2022 9:51 am That mirror broke many tests because someone decided to replace all LF characters with CR/LF in all files (including the test data files), and there was also code added but no tests written or adapted to the changed code. The tests were ignored and they are useless now.
Now here's the weird thing.
- Most tests fail unless run from inside the test directory. I did not know that and ran them from the root of the repo, causing lots of failures.
- A dynamic version of 11.3 passes all tests (in your repo, not in the clone).
- A static version of 11.3 fails many tests with one of these errors:
"../nativefs.lua:351: /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_getMountPoint"
"../nativefs.lua:248: /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol: PHYSFS_mount"
That's probably what Ross was experiencing.
- Either a dynamic or static version of 11.4 (doesn't seem to matter) passes all tests but one:
Code: Select all
Started on Sat Jul 9 14:02:29 2022
test_File_flush ... Ok
test_File_isEOF ... Ok
test_File_lines ... Ok
test_File_open ... Ok
test_File_read ... Ok
test_File_seek ... Ok
test_File_setBuffer ... Ok
test_File_tell ... Ok
test_File_write ... Ok
test_fs_append ... Ok
test_fs_createDirectory ... Ok
test_fs_getDirectoryItems ... Ok
test_fs_getDirectoryItemsInfo ... Ok
test_fs_getDriveList ... Ok
test_fs_getInfo ... Ok
test_fs_lines ... Ok
test_fs_load ... Ok
test_fs_mount ... Ok
test_fs_newFile ... Ok
test_fs_newFileData ... Ok
test_fs_read ... FAIL
main.lua:77: expected: 446, actual: nil
test_fs_remove ... Ok
test_fs_setWorkingDirectory ... Ok
test_fs_write ... Ok
test_xxx_globalsCheck ... Ok
It's a possibility that the fact that a static 11.4 build finds PhysFS, unlike 11.3, has to do with me having used cmake instead of autotools for building, but I'm not sure what I actually used for each of the builds so I can't be sure.
Thanks a lot for providing it. You had other valuable repositories and I wonder if it would be possible for you to provide them. I only have cindy and moonvox, both of which I could put online but it appears there were more - I didn't even know about nativefs. It's OK if you wanted to stop maintaining them, but you could just have archived them instead of deleting them. It's been a great loss.
I'll look into that.grump wrote: ↑Sat Jul 09, 2022 9:51 am P.S.: In retrospect, test_fs_lines() should not use main.lua as its test corpus, because it assumes LF line endings in test/main.lua. That's a bogus assumption (line endings in code can change inadvertently when mixing OSs) that should be fixed by the potential new maintainer, if they care about tests passing.
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
Note that the test files intentionally have both kinds of line breaks, because the lines() function should be tested to work properly with LF and CR/LF line endings. Normalizing them is not a good idea. This could have been documented better I guess.
I don't think I ever ran the tests against the final 11.4 release, just some pre-release build. The failing test suggests that there's been a change in what love.filesystem.read returns.
Re: Errors with filesystem libraries (Solved - problem with Löve installation on Linux Mint)
I think I've made it right. Normalizing means that inside the repository they have LF line endings, as that's what Git uses internally in order to be able to manage line endings. I've set one file to eol=lf and the other to eol=crlf; this means that on checkout, Git will transform one of the files to always have LF line endings and the other to always have CR/LF line endings, regardless of the OS. I believe (but I have not tested) that if they are ever edited and that changes their line endings, the committed versions will remain normalized on commit, and will receive the proper line endings on checkout. I think that's desirable (unless a mix of LF and CRLF is wanted within the same file, in which case binary would be a better choice).
Thanks, I'll look into that as well.
- Gunroar:Cannon()
- Party member
- Posts: 1142
- Joined: Thu Dec 10, 2020 1:57 am
Who is online
Users browsing this forum: Google [Bot] and 11 guests