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
On Thu, Nov 16, 2000 at 10:25:17AM -0800, Ian Lance Taylor wrote:
>
> > We must also consider the case of (1), (2), and (3) as above, but now
> > in a regular object file we have (5) "foo" with version "ver1" but
> > where (5) is not the default version. Presumably (1) should resolve
> > to (5). Should (2) also resolve to (5)? If (2) does resolve to (5),
> > that implies that a default version (3) can somehow loan its default
> > character to a symbol (5) with the same name and version, but which is
> > not the default. That seems strange.
>
> 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
>
> You will see what I mean. Both the dyanmic linker and static linker
> have to deal with it. See
>
> 2000-02-22 H.J. Lu <hjl@gnu.org>
>
> * elflink.h (elf_link_add_object_symbols): If a version symbol is
> not defined, don't add a second ELF_VER_CHR.
>
> Banning the versioned references in asm code doesn't solve the problem.
> The problem you described is nothing new. It can/will happen if we are
> not careful. I guess we have to document how we should use it. Since
> the symbol versioning was motivated by libc. We can just say the symbol
> versioning can only be used by the system libraries, similar to the
> weak symbol.
>
> I wouldn't want to make any restrictions for system vs. non-system
> libraries, but it might be correct to make restrictions for shared
> objects vs. object files.
>
I am enclosing a new test which also tests shared library:
# make
cc -g -O -c -o main1.o main1.c
cc -c -g -O -fPIC ref1.c
cc -c -g -O -fPIC ref2.c
cc -c -g -O -fPIC foo.c
cc -shared -o libfoo.so foo.o -Wl,--version-script,libfoo.map
cc -o test1 main1.o ref1.o ref2.o libfoo.so -Wl,-rpath,.
./test1
foo, ver1: 30
foo: 30
cc -shared -o libref1.so ref1.o -Wl,--version-script,libref1.map
cc -shared -o libref2.so ref2.o -Wl,--version-script,libref2.map
cc -o test1a main1.o libref1.so libref2.so libfoo.so -Wl,-rpath,.
./test1a
foo, ver1: 30
foo: 30
cc -g -O -c -o main2.o main2.c
cc -o test2 main2.o libref1.so libref2.so libfoo.so -Wl,-rpath,.
libfoo.so(*IND*+0x0): multiple definition of `foo@ver1'
main2.o:/user/hjl/bugs/gas/version11/main2.c:13: first defined here
collect2: ld returned 1 exit status
make: [test2] Error 1 (ignored)
cc -o test2a main2.o ref1.o ref2.o libfoo.so -Wl,-rpath,.
libfoo.so(*IND*+0x0): multiple definition of `foo@ver1'
main2.o:/user/hjl/bugs/gas/version11/main2.c:13: first defined here
collect2: ld returned 1 exit status
make: [test2a] Error 1 (ignored)
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.
--
H.J. Lu (hjl@valinux.com)
bug.tar.gz