This is the mail archive of the
mailing list for the glibc project.
[Bug dynamic-link/12977] glibc dynamic linker behaves unpredictable when using base version
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 18 Jan 2017 18:24:16 +0000
- Subject: [Bug dynamic-link/12977] glibc dynamic linker behaves unpredictable when using base version
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Diego Barrios Romero from comment #3)
> At run time, the symbol f that is requested by BU with version B_1.0 gets
> matched with the base version one provided by library A. Even though the
> symbol with the adequate version is also available, the base version is
Do you really mean “base version” here? Isn't this an unversioned symbol?
Ulrich Drepper's description of symbol versioning is pretty clear that
unversioned symbols preempt all versioned symbols of the same name, no matter
what the symbol version is. I believe the original intent for this design
choice was that it allows to introduce symbol versioning in a future library
version, while still permitting existing binaries to interpose those symbols.
No matter what the original choice was, we today have many interposing
libraries (such as alternative malloc implementations) which depend on this
particular behavior of the dynamic linker.
I agree this behavior is surprising, but the behavior described in comment 3
does not qualify as a bug.
Let's keep this bug open for the original issue (dlsym result depends on hash
chain ordering in a surprising way).
You are receiving this mail because:
You are on the CC list for the bug.