This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/19884] Discrepancy between documented and actual search path for shared libraries
- From: "njs at pobox dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 11 Apr 2016 03:43:08 +0000
- Subject: [Bug dynamic-link/19884] Discrepancy between documented and actual search path for shared libraries
- Auto-submitted: auto-generated
- References: <bug-19884-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19884
--- Comment #5 from Nathaniel J. Smith <njs at pobox dot com> ---
> If you have two libraries with the same SONAME then I think you are entering undefined territory
In what sense is it undefined?
Right now the documentation defines very clearly what will happen in this case
-- it just turns out that the code does something different :-). So it's not
undefined in the sense of the C specification's explicit "invoking undefined
behavior". If it should be undefined, then at the least the docs should be
updated to say that.
Or maybe you mean "the behavior in this case *should* be undefined" -- usually
I guess the rationale for this would be that there is no good answer to what
should happen, so there's not a lot of value in pinning down the behavior, and
there is some value in allowing different implementations to treat it
differently. But I don't see how that argument applies here. The whole ELF
scopes mechanism goes to great lengths to make it possible to provide
"plugin-style" shared libraries that can be loaded at runtime into a host and
are isolated from each other so that the authors of different plugins don't
need to coordinate. (For those who haven't just spent a few hours poring over
dsohowto: the way ELF scopes work is that for libraries loaded via dlopen(...,
RTLD_LOCAL), some elaborate work is done to make sure that each library gets
its own tree of dependent libraries and symbol resolution scope, so that you
can't get accidental symbol collisions between two libraries loaded this way.)
So IMO it's a shame that after going to all this trouble to provide isolated
symbol scopes, we allow two plugins to crash into each other and break
everything if they happen to link to different versions of the same library
that have the same SONAME.
And this isn't hypothetical at all -- we actually hit this problem, using an
actual library that has different non-interchangeable versions that share the
same SONAME. We hit it with libgfortran, but it applies equally well to other
language support runtime libraries, like, say, libstdc++. If I have the very
common situation of a plugin that uses C++ internally but presents a C API to
the external world, then I should be able to ship a private copy of libstdc++
with my plugin without worrying that loading my plugin into some host process
will cause every other piece of C++ code loaded into that process to blow up.
--
You are receiving this mail because:
You are on the CC list for the bug.