19

I'm a newbie to distutils and I have a problem that really has me stuck. I am compiling a package that requires an extension, so I make the extension thus:

    a_module = Extension(
          "amodule",
          ["initmodule.cpp"],
          library_dirs=libdirs,
          extra_objects = [
                    "unix/x86_64/lib/liba.so"
                    "unix/x86_64/lib/lib.so",
                    "unix/x86_64/lib/libc.so"],
    )

I then run the setup method:

    setup(name="apackage", version="7.2",
      package_dir = {'':instdir+'/a/b/python'},
      packages=['apackage','package.tests'],
      ext_modules=[hoc_module]
)

The package distribution is made properly and I can "python setup.py install" fine but when I try and import my package I get an error ImportError: liba.so.0: cannot open shared object file: No such file or directory

I realise that when I add the location of liba.so.0 to my LD_LIBRARY_PATH the program runs fine. Unfortunately I haven't written these modules and don't have a good understanding of compilation. I've been trying to figure this out for several days to no avail.

UPDATE:I tried passing the liba.a, libb.a etc files to extra_objects but this didn't work, generating the following errror: liba.a: could not read symbols: Bad value collect2: ld returned 1 exit status. What I'm trying to do is package a python module which requires a library to be compiled which itself depends on other libraries which I need to somehow include in the package .I suspect that my problem is very similar to this one: http://mail.python.org/pipermail/distutils-sig/2009-February/010960.html but that one was not resolved, I thought perhaps since it's two years old a resolution has been found?

UPDATE 2: For now I have solved this by doing:

      data_files=[('/usr/local/lib', glob.glob('unix/x86_64/lib/*'))]

That is to say, I am copying the libraries I need into /usr/local/lib. I'm not hugely happy with this solution however, not least because it requires my users to have root privileges and also because this may still not work Redhat distros. So if anyone can suggest something better than this fix do please let me know.

Mike Vella
  • 10,187
  • 14
  • 59
  • 86

2 Answers2

17

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 required
gcc -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-time
gcc -o blah blah.o -lpcap -Wl,-R/opt/csw/lib

# LD_LIBRARY_PATH not needed at link or run-time
gcc -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-time
gcc -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
Brian Vandenberg
  • 4,011
  • 2
  • 37
  • 53
  • Fantastic answer, by combining your answer with this http://sebsauvage.net/python/mingw.html I was able to build the needed module in exactly the required way. Thank you so much. – Mike Vella Apr 23 '12 at 16:24
  • Not a problem, I'm glad I could help – Brian Vandenberg Apr 23 '12 at 17:04
  • 4
    FYI: Instead of adding the `-R'$ORIGIN/../lib/'` option, you can add `runtime_library_dirs="$ORIGIN/../lib/"` to your `Extension` definition (it does the same thing in practice). – David Robinson Jul 12 '12 at 17:42
  • Keep in mind, however, that `runtime_library_dirs` is python specific. – Brian Vandenberg Jul 12 '12 at 19:14
  • I should've warned/cautioned something when using `$ORIGIN`: `ldd` will only use fully qualified paths at runtime if the application is ran with suid/setuid. Not every OS handles it the same; some may just skip paths with `$ORIGIN` entirely, others I've seen will just use the string verbatim (ie., using `truss`/`strace` you'd see an attempt to open `$ORIGIN/../lib/libsomelib.so`). – Brian Vandenberg Oct 01 '13 at 17:22
  • I had to use "-Xlinker -R" with gcc rather than just "-R" when compiling. This is to make sure the argument is passed to the linking step rather than the compilation step. – Tobias Bergkvist Sep 24 '20 at 10:15
  • does `runtime_library_dirs` work when user installs the wheel? is this runtime related to during creation of wheel or during installation of the wheel? – Chaitanya Bapat Jan 11 '21 at 06:47
11

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.)

Thomas Wouters
  • 130,178
  • 23
  • 148
  • 122
  • Thank you so much for your detailed and excellent reply. Am I correct in understanding that runtime_library_dirs should be set as a relative path then, otherwise I don't see how it can be hardcoded? Also, should I pass the statically linked libraries (i.e the liba.a archives) to the libraries or extra_objects keywords. Unfortunately the documentation isn't helping me much on these two questions. – Mike Vella Mar 20 '12 at 23:02
  • 1
    Passing a relative directory as runtime_library_dirs can be done, but it's not a good idea (because the extension module moves around during the build process, and the same path would have to work for all.) As for linking statically, you can try passing the `.a` archives as the `extra_objects` argument, although that isn't what `extra_objects` is for and I'm not sure if it'll work. Perhaps you should elaborate on what you actually want to do. – Thomas Wouters Mar 20 '12 at 23:05
  • Thanks for your reply, I have added some more detail to my original question. – Mike Vella Mar 20 '12 at 23:19
  • OK - I've figured out that a way to solve my issue is to place the libraries in /usr/lib I realise this isn't quite ideal but is there any major reason I shouldn't do this? – Mike Vella Mar 21 '12 at 04:51
  • 1
    No, placing shared libraries in locations that the dynamic linker already considers is common practice. The only reason not to do it is if something else, like the OS's package manager, controls `/usr/lib`, in which case your files may be in the way when you later install some other OS package. `/usr/local/lib` is a better choice (and exists for that very purpose.) You can also use some other location and tell the dynamic linker to consider it (through `/etc/ld.so.conf` or the `ldconfig -m` command or such.) – Thomas Wouters Mar 21 '12 at 20:32
  • It appears to work well with /usr/local/lib - however my concern with going down this route is that not searched for shared objects in Redhat/Fedora. Is there an accepted way to deal with this situation? – Mike Vella Mar 22 '12 at 00:50
  • Why would a parameter called `runtime_library_dirs` have any effect on the compiling or linking phase? I would expect this to be a folder, possible included in the python egg, which contains `.so`'s or similar used whenever you do `import some_package` (i.e. the runtime). That is what the name suggests and also what I would make of the documentation here: https://docs.python.org/3.5/distutils/apiref.html – Herbert Jun 24 '16 at 10:57