Shared library dependencies with distutils

You can have the linker store paths to search in the output binary so LD_LIBRARY_PATH isn't necessary. Some examples:

# Will link fine but at run-time LD_LIBRARY_PATH would be requiredgcc -o blah blah.o -lpcap -L/opt/csw/lib# Without LD_LIBRARY_PATH=/opt/csw/lib it will fail to link, but# it wouldn't be needed at run-timegcc -o blah blah.o -lpcap -Wl,-R/opt/csw/lib# LD_LIBRARY_PATH not needed at link or run-timegcc -o blah blah.o -lpcap -Wl,-{L,R}/opt/csw/lib# This makes it possible to use relative paths; run `readelf -d binary_name`# and you'll see '$ORIGIN/../lib/' in RPATH.  This plus `-zorigin` make it look# relative to the binary for libraries at run-timegcc -o blah blah.o -lsomelib -L/whatever/path/floats/your/boat -Wl,-R'$ORIGIN/../lib/' -Wl,-zorigin

.. where:

• paths given with -L are used at link-time
• paths given with -R are used at run-time

The extra_objects argument to the Extension class is not so much a list of libraries to link into your extension, but a list of object files that will be passed to the linker (and the filenames shouldn't include extensions, since distutils will add those.) It doesn't do what you seem to want.

If you want to link against specific shared libraries, as the names of those files suggest you want, you have to do two things: tell distutils to tell the compiler to link against those shared libraries, and tell the dynamic linker (usually ld.so) where to find those shared libraries. You can tell distutils to tell the compiler to link against the libraries by using the libraries argument to Extension, which should be a list of library names (without the lib prefix and .so suffix.) In your example that seems to be ['a', 'b', 'c'] (although it looks like the 'b' fell off of 'lib.so', and 'c' would actually clash with the system libc.)

Telling the linker where to find these shared libraries can be done by setting the LD_LIBRARY_PATH environment variable, as you did, or by changing a system-wide configuration setting (with ldconfig or by editing /etc/ld.so.conf), or by hardcoding the search path in the extension module; you can do the latter by passing the runtime_library_dirs argument to Extension. Hardcoding the path does have its own issues, though -- you have to keep those libraries in the same place, and accessible to all users of the extension module.

(Alternatively, you can use static instead of dynamic linking, for example by only providing the libraries in static form, liba.a archives (in which case distutils will automatically link to them statically.) That basically means the whole library is included in the extension module, which has various downsides and upsides.)