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

[Peter Colberg]

On Thu, Nov 05, 2015 at 02:51:38PM -0500, Peter Colberg wrote:
> On the other hand, there might be external Julia packages that
> dynamically load these libraries as well, and expect them to
> be available since they are used in Base.

This is the case. For a quick code search on Github for ccall, I found
an example for a package that loads Base.libblas_name, and another one
that loads :libgmp.

https://github.com/aaronokano/TallSkinnyQR.jl/blob/bfe8d44fbc36c6fe5bc467dd835a1a677afbbd03/src/helpers.jl
https://github.com/andrioni/BigRationals.jl/blob/c2335910fea439f630a4427100da90db184dfe70/src/BigRationals.jl

If the julia source were patched to explicitly load libraries by
soname, external packages could still load a different version of
the same library into the interpreter depending on the order in
which ldconfig lists them. I am not sure if it is a good idea
to have conflicting ABIs of the same library in one process.

Creating .so symlinks in Julia’s private libdir would at least ensure
that the set of those libraries used by Base is stable and predictable.

Besides generating symlinks and binary depends automatically, I am
inclined to disable the fallback to ldconfig altogether. This means
that ccall(…, :libfoo) considers only libfoo.so, but not libfoo.so.X
or libfoo.so.Y.

That way an error is produced (on a machine without -dev packages)
for the case when a new library dependency is added to Base and we
forget to make a .so → .so.MAJOR symlink in Julia’s private libdir.

For external packages that do not specify the soname of a library
dependency, it would be expected that the user installs the -dev
package providing the .so symlink for that library.

This should be reasonable, given that for some libraries the soname
does not even match the .so name loaded by a julia package (e.g.,
HDF5.jl loading libhdf5.so pointing to libhdf5_serial.so.VERS).

Peter