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

[Ross]

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.

[pgimeno]

Interesting. How big is the love executable? Is it in the few tens of kB range or more like in the tens of MB?

[Ross]

It's 4.1 MB.

[pgimeno]

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:

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

I haven't investigated the cause, but maybe NativeFS doesn't like statically linked executables.

[grump]

I've tried the unit tests from NativeFS (https://github.com/EngineerSmith/native ... /main/test) and many failed. Here's the report:

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.

I haven't investigated the cause, but maybe NativeFS doesn't like statically linked executables.

Yeah, the PhysFS ffi imports will only work with .so/.dll linkage.

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.

[pgimeno]

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

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.

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.

I haven't investigated the cause, but maybe NativeFS doesn't like statically linked executables.

Yeah, the PhysFS ffi imports will only work with .so/.dll linkage.

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

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.

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.

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.

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.

I'll look into that.

[grump]

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.

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.

[pgimeno]

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 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).

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.

Thanks, I'll look into that as well.

[Gunroar:Cannon()]

...grump?