Changaco / python-libarchive-c

Python interface to libarchive
Other
70 stars 37 forks source link

This package does not work if libarchive.so is missing but libarchive.so.13 exists #128

Closed mxmlnkn closed 4 months ago

mxmlnkn commented 4 months ago

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:

docker run -it quay.io/pypa/manylinux2014_x86_64 bash
yum install -y fuse fuse-libs lzip
cd ~
lzip -k anaconda-ks.cfg
wget https://github.com/mxmlnkn/ratarmount/releases/download/v0.15.0/ratarmount-0.15.0-x86_64.AppImage
./ratarmount-0.15.0-x86_64.AppImage --appimage-extract
squashfs-root/AppRun anaconda-ks.cfg.lz mounted

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:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/ratarmount.py", line 44, in <module>
    import ratarmountcore as core
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/ratarmountcore/__init__.py", line 47, in <module>
    from .compressions import (
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/ratarmountcore/compressions.py", line 64, in <module>
    import libarchive
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/__init__.py", line 1, in <module>
    from .entry import ArchiveEntry
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/entry.py", line 6, in <module>
    from . import ffi
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/ffi.py", line 158, in <module>
    version_number = ffi('version_number', [], c_int, check_int)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/ffi.py", line 102, in ffi
    f = getattr(libarchive, 'archive_'+name)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/ctypes/__init__.py", line 392, in __getattr__
    func = self.__getitem__(name)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/squashfs-root/opt/python3.12/lib/python3.12/ctypes/__init__.py", line 397, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: /root/squashfs-root/opt/python3.12/bin/python3.12: undefined symbol: archive_version_number

Adding further debug output in /root/squashfs-root/opt/python3.12/lib/python3.12/site-packages/libarchive/ffi.py shows that find_library seems to return nothing:

libarchive_path = os.environ.get('LIBARCHIVE') or find_library('archive')
print("libarchive_path:", libarchive_path)
print("LIBARCHIVE:", os.environ.get('LIBARCHIVE'))
print("find_library:", find_library('archive'))
libarchive = ctypes.cdll.LoadLibrary(libarchive_path)

Output:

libarchive_path: None
LIBARCHIVE: None
find_library: None

After ( cd squashfs-root/usr/lib/ && ln -s libarchive.so{.13,} ), the output is:

libarchive_path: libarchive.so.13
LIBARCHIVE: None
find_library: libarchive.so.13

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 for find_library to find the correct .so even though libarchive.so is not installed. So maybe it is some weird intricacy with parsing LD_LIBRARY_PATH?

Changaco commented 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.

mxmlnkn commented 4 months ago

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.