3.3.0 pypi wheels are not valid manylinux wheels

[anntzer]

This can be checked using auditwheel

$ auditwheel show prox_tv-3.3.0-cp37-cp37m-manylinux1_x86_64.whl
prox_tv-3.3.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libstdc++.so.6 with versions {'CXXABI_1.3',
'GLIBCXX_3.4'}, libgomp-3300acd3.so.1.0.0 with versions {'GOMP_1.0',
'OMP_1.0'}, libc.so.6 with versions {'GLIBC_2.4', 'GLIBC_2.2.5',
'GLIBC_2.3'}, libm.so.6 with versions {'GLIBC_2.2.5'}, librt.so.1 with
versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.2.5', 'GLIBC_2.3.4'}

The following external shared libraries are required by the wheel:
{
    "libblas-2d5b9174.so.3.0.3": null,
    "libc.so.6": "/lib/libc-2.28.so",
    "libgcc_s.so.1": "/lib/libgcc_s.so.1",
    "libgfortran-bfa58d52.so.1.0.0": null,
    "libm.so.6": "/lib/libm-2.28.so",
    "libpthread.so.0": "/lib/libpthread-2.28.so",
    "librt.so.1": "/lib/librt-2.28.so",
    "libstdc++.so.6": "/lib/libstdc++.so.6.0.25"
}

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libblas-2d5b9174.so.3.0.3, libgfortran-bfa58d52.so.1.0.0

or by installing prox_tv==3.3.0 on an Arch Linux system and trying to import it:

$ python -c 'import prox_tv'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.7/site-packages/prox_tv/__init__.py", line 64, in <module>
    from _prox_tv import ffi, lib
ImportError: /usr/lib/python3.7/site-packages/_prox_tv.abi3.so: ELF load command address/offset not properly aligned

[albarji]

Thanks for reporting this. I thought I had everything covered here... but actually I only tried this under Ubuntu, as this is the distro Travis supports.

I was aware of the auditwheel message complaining about "missing" shared library dependencies, but this works perfectly well anyhow, so I guess those "libblas-2d5b9174.so.3.0.3" are some renaming of library references made by cffi, which manages to resolve at running time to the actual bundled libblas.

However I'm a bit confused about the ELF address misalignment. Any ideas on this?

[anntzer]

Not sure what's exactly happening in this case (especially, I don't know how cffi does its thing), but for https://github.com/anntzer/mplcairo where I have an extension that needs to load symbols from libcairo, my solution is to explicitly not link the .so against libcairo, but rather globally load the symbols at runtime via pycairo vu doing ctypes.CDLL("/path/to/pycairo.so", ctypes.RTLD_GLOBAL). This ensures that all the symbols in libcairo.so are globally available to the process, and thus in particular to the extension module. Perhaps a similar strategy can work in your case?

In any case, it would also be nice if you could also publish sdists to PyPI, this was at least everyone can build their own packages locally.

[albarji]

I have been running some tests on an ArchLinux container, and everything seems to work ok. In particular, you can run

docker run --rm -it base/archlinux bash -c "pacman -Sy --noconfirm python; pacman -Sy --noconfirm python-pip; pip install prox_tv; python -c 'import prox_tv; print(\"OK\")'"

and this works in my 64 bit laptop. Maybe you are having an issue because of different hardware architecture?

[albarji]

Also, publishing also sdists might be a good idea. Will take a look at that.

[anntzer]

This is what uname -a gives me:

Linux antony1 4.18.16-1-ck-haswell #1 SMP PREEMPT Sat Oct 20 08:21:44 EDT 2018 x86_64 GNU/Linux

Admittedly the situation is a bit confusing...