This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

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


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