BasePackage.find_runtime_path() fails when .so file is a linker script

[mgorny]

I've been trying to debug the following setup.py error:

* Found LZO 2 headers at ``/usr/include``, library at ``/usr/lib64``.
.. WARNING:: Could not find the LZO 2 runtime.
   The LZO 2 shared library was *not* found in the default library
   paths. In case of runtime problems, please remember to install it.

I've finally been able to establish that it's attempting to load libbz2.so via ctypes which results in the following error:

libbz2.so failed: /usr/lib64/libbz2.so: invalid ELF header

This is because /usr/lib64/libbz2.so is GNU ld script, and therefore is not suitable for being loaded directly. It has the following contents:

/* GNU ld script
   Since Gentoo has critical dynamic libraries in /lib, and the static versions
   in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
   run into linking problems.  This "fake" dynamic lib is a linker script that
   redirects the linker to the real lib.  And yes, this works in the cross-
   compiling scenario as the sysroot-ed linker will prepend the real path.

   See bug https://bugs.gentoo.org/4411 for more info.
 */
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/libbz2.so.1 )

The C compiler's -lbz2 results in executables being linked to libbz2.so.1 and this is the executable that the setup script should be loading.

In general, trying to load shared libraries via .so files rather than SONAME is a bad idea. If you insist on testing for working runtime, it is generally a better idea to actually create a temporary shared library that links -lbz2 and try to load that (since you can predict the created library name).

[avalentino]

Thanks for reporting @mgorny.
Unfortunately our setup.py script is very complex and it is not in a good shape.

As far as I can remember the runtime check is mostly relevant for windows platforms.
I'm not even sure that it is still the case.

If you have a better approach we would really appreciate a pull request.