This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/19884] Document libdl API in glibc to describe loading process in detail.
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 10 Aug 2016 16:14:31 +0000
- Subject: [Bug dynamic-link/19884] Document libdl API in glibc to describe loading process in detail.
- Auto-submitted: auto-generated
- References: <bug-19884-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19884
--- Comment #11 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Nathaniel J. Smith from comment #2)
> *If* the same library is loaded twice, then having the two copies share
> state makes perfect sense. The problem here is that according to all the
> library lookup rules, we're actually loading two different libraries that
> live in two different files at two different locations, yet they still end
> up sharing state...
>
> Yes, the two different libraries have the same SONAME, but there's no
> guarantee that all libraries with a given SONAME will be interchangeable.
That is wrong. That's exactly what having the same SONAME means.
> "interchangeable" means fully backwards *and* forward compatible, and that's
> not even true for basic libraries like glibc or libgcc.
It is true, but the story is more complicated.
With the advent of symbol versioning the state became a tuple { SONAME,
<Versioned symbols> }, where symbol versions extended the SONAME described
interface.
> (Actually, I'm not even sure how much state the two copies share -- since
> they're in different scopes they get different relocation processing, right?
No. The DSO is mapped only once and has relocations processed only once. The
first loaded library wins.
> I guess those are in a different segment or something, so the two copies
> share .data but not relocations or something?)
No.
--
You are receiving this mail because:
You are on the CC list for the bug.