[Pkg-julia-devel] [SCM] Julia branch master updated. debian/0.3.11-1-20-gdbf6516

[Peter Colberg]

Hi Graham,

On Thu, Nov 05, 2015 at 11:24:44AM +0200, Graham Inggs wrote:
> What problem is this trying to solve?

Seeing the manually maintained list of libraries in Depends:, I was
curious how Julia knows to load the right library version by soname
when libname-dev is not installed. It turns out it does not.

If ccall() is passed a library name without suffix, it will try to
open "libname.so". If that fails, `/sbin/ldconfig -p` is queried for
libname to extract a matching soname. It appears it chooses whatever
soname is last in the output of ldconfig, regardless of whether that
is an older or newer version, or whether it satisfies the ABI
requirements of Julia.

The end result is that the set of library sonames is unpredictable
and depends on the installed library versions on a users machine.

I could produce a segmentation fault in Base.runtests() by having
Julia load a mixed-versioned set of suitesparse libraries through
explicit symlinks.

> I don't think trying to maintain this list of links in the julia package is
> a solution.

I think so too unfortunately.

This is however the least invasive solution to ensure that the
libraries in the Depends: field are actually used, not a random
set of installed libraries with matching library names.

A long-term solution could be to generate the library sonames
at installation time, store these as constants in build_h.jl,
and use the constants in base instead of hard-coded libnames.

I have implemented a comparable solution before [1] in an FFI module
for the LuaJIT interpreter/compiler, using dladdr() to query the
soname given the name of a function from that library.

[1] http://git.colberg.org/lua-hdf5/tree/hdf5/hdf5.c

This is better implemented working closely with upstream, and in
Julia 0.5. I assume the first step is to convince upstream that
soversions are not a hindrance (and circumvented by matching
`/sbin/ldconfig -p`) but rather useful for providing an admittedly
distribution-dependent but predictable library environment.


Do you see a better solution for loading the right soversions?

Regards,
Peter