[Bug dynamic-link/19884] Discrepancy between documented and actual search path for shared libraries

["njs at pobox dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19884

--- Comment #7 from Nathaniel J. Smith <njs at pobox dot com> ---
> Nathaniel, it occurred to me that your use case is not helped at all if we fixed this in glibc *now*.  We'd need a time machine to fix this in the EL5 time frame, so that you get binary compatibility with libcs from that era.

Right, this bug report is more by way of being a good citizen -- I don't expect
any response to this bug report to directly improve my life anytime in the next
5 years, but at least if I report it now then there's some chance that it
*will* be fixed and in 5 years it might do me some good :-).

> Therefore, I suggest we move the discussion to libc-help and find a way you can build DSOs for Python modules so that they do not exhibit this problem

In fact we've already worked around it. The workaround is rather complicated --
it involves a script that renames all our $(NAME).so files to
$(NAME)-$(CONTENTHASH).so, and then uses patchelf[1] to fix up the embedded
sonames and all DT_NEEDED entries to refer to the new names. (Also, to make
this work you need some fixes to patchelf that aren't even fully merged
upstream yet...[2][3].) But it works well for our use case, and I don't see any
other approach.

I am aware though of at least one other use case that this bug is impacting,
and where there is no workaround, and where a fix now would actually do some
good within a reasonable time frame. The conda package manager [4], which is
extremely popular in the scientific programming world, ships its own version of
runtime libraries like libgfortran and libstdc++. This causes problems in the
following situation: (1) you are using some python or R or whatever extension
modules from conda, which are linked against the conda libgfortran, (2) you
build a python or R extension module on your own machine, using your system
version of GCC, so this extension module requires libgfortran >= your system's
version, (3) you try to use this extension module in the same process as the
extension modules that ship with conda, and so -- because of this bug -- your
extension module ends up linked against conda's libgfortran, (4) your system
has a newer version of libgfortran than conda does, so this blows up.

Currently the conda maintainers "workaround" to this problem is just to be
really quick about updating the libgfortran that they ship whenever a new
version is released, in the hopes of making sure that no user ever ends up in a
situation where their compiler is newer than their conda install. But this is a
bandaid at best. And, it's a case where fixing this bug would actually make a
difference in the short term, because the case that breaks right now is systems
that are aggressive about upgrading their gcc; so it doesn't matter if RH5's
glibc will never be updated, because its gcc will never be updated either, and
system who do keep aggressively up to date on gcc probably also keep
aggressively up to date on glibc.

[1] https://github.com/NixOS/patchelf
[2] https://github.com/NixOS/patchelf/pull/85
[3] https://github.com/NixOS/patchelf/pull/86
[4] http://conda.pydata.org/docs/

-- 
You are receiving this mail because:
You are on the CC list for the bug.