Closed mxmlnkn closed 4 months ago
The find_library
function is from the Python standard library module ctypes.util
. You can find its platform-specific implementations in https://github.com/python/cpython/blob/main/Lib/ctypes/util.py. Any bug or shortcoming in any of those implementations should be reported and fixed upstream.
That's what I feared. I'll simply set the LIBARCHIVE
environment variable and/or create a symbolic link manually for now as I don't have the optimism to file this as a bug report against Python.
There are two bugs in my opinion:
This has the combined weird effect that users need to install the libarchive development package even though the normal library package should have been sufficient.
See also https://github.com/mxmlnkn/ratarmount/issues/137#issuecomment-2136274113
Reproduce with:
After disabling the try-import-pass of libarchive in
/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/ratarmountcore/compressions.py
, the thrown exception is shown to be:Adding further debug output in
/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/ffi.py
shows thatfind_library
seems to return nothing:Output:
After
( cd squashfs-root/usr/lib/ && ln -s libarchive.so{.13,} )
, the output is:Weirdly enough, this only seems to be an issue with the AppImage library. Installing the non-devel version with
yum install libarchive
is also sufficient forfind_library
to find the correct .so even though libarchive.so is not installed. So maybe it is some weird intricacy with parsingLD_LIBRARY_PATH
?