This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]