This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: A patch for default version and archive
Date: Sat, 18 Nov 2000 17:49:29 -0800
From: "H . J . Lu" <hjl@valinux.com>
> Like it or not, even if we don't do explicit versioned references
> today, it is here thanks to shared libraries. Just do
>
> # nm /usr/lib/lib*.so | grep GLIBC
>
> Those are references to versioned symbols within a shared library,
> aren't they? I see them only in the ordinary symbol table, not in the
> dynamic symbol table. In a shared library, the dynamic symbol table
Then try
# objdump --dynamic-sym /usr/lib/lib*.so | grep GLIBC
# objdump --dynamic-sym /usr/X11R6/lib/lib*.so | grep GLIBC
No, that's different. That is versioned symbols doing what they were
originally designed to do, namely refer to specific versions in other
shared libraries. Those version numbers were inserted by the program
linker based on the version numbers it found in shared libraries at
the time it did the link. They do not (necessarily) reflect any
occurrence of explicit versioned references in object files.
The versioned reference is consistent with both shared and regular
objects. That is what I expected. We have versioned references in
shared library today. I don't believe there is anything seriously wrong
with versioned references in regular objects.
Except for the behaviour of the default version, a version number is
for all practical purposes part of the symbol name. The behaviour of
the default version appears confusing when used with regular objects.
What advantage do we get by permitting versioned references in regular
objects? Using an explicit version means that you don't want to use
the default symbol. So why can't you just use a symbol name? For
example, anybody who wants to use an explicit version reference could
simply define an alias for the symbol which defines the version.
Wouldn't that provide exactly the same functionality without the
confusion associated with default versions?
Ian