dlopen() sonames

[opoplawski]

julia really should dlopen() the appropriate soname for a given library. This will serve at least two purposes:

• Ensure you are loading the proper, compatible version of the library.
• Avoid requiring the install of -devel package on Linux.

[JeffBezanson]

Do you have any guidance on how to accomplish this?

[StefanKarpinski]

I'm also unclear on what this means. Could you elaborate?

[opoplawski]

Not saying it's easy :). e.g. when julia tries to open fftw, it searches for libfftw3_threads.so. However, on most Fedora user's systems libfftw3_threads.so is only installed if they installed fftw-devel. It is a symbolic link to the actual library: libfftw3_threads.so.3.3.2. That library also has a soname which indicates the version of the library, in this case libfftw3_threads.so.3, which is also a link to the library. This is installed on any machine that needs to use the fftw library. If a program is linked against a particular soname (libfftw3_threads.so.3) it will not work against a different version of the library. Library sonames are bumped to indicate API/ABI incompatibility with previous versions.

I'm honestly not terribly familiar with the issues that come up with using dlopen() to open libraries instead of compile time linking, but in general one should reference the soname instead of the .so name. At least on Fedora using the .so would require installing many -devel packages for run-time use by julia that really shouldn't be needed. It is also causing problems building julia in the mock build environment because the .so library names generally don't make it into /etc/ld.so.cache.

Hope that helps.

[nolta]

I think he wants us to dlopen("libX.so.1") instead of dlopen("libX.so"), because linux distributions often don't install the libX.so -> libX.so.1 symlink. This is the problem i wrote extras/openlib.jl to work around.

[StefanKarpinski]

Oh, yeah, ok. Well, maybe we should just make openlib standard?

[opoplawski]

Yeah, looks like openlib() does the right thing.

[nolta]

Maybe, although openlib's a bit of a hack. Here's another option: 9ff08e9 (on the 'dlopen' branch). It adds dlopen(name, version).

[ViralBShah]

This is an issue on Debian also, and is currently preventing me from proceeding on debian packages where the .so name is only provided by dev packages. dlopen(name, version) is great, but how does one find the installed version? If the dlopen branch does that, then it's time to merge it in. Also, we could probably move much of dlopen.c (or all of it?) into julia code.