| Index Nav: |
Date Index] [Subject Index] [Author Index] [Thread Index]
|
|---|
| Message Nav: |
[Date Prev] [Date Next d>
| [Thread Prev] [Thread Next] |
|---|
able>
Re: A patch for default ion and archive
On Wed, Nov 15, 2000 at 10:04:58AM -0800, Ian Lance Taylor wrote:
> Ok, let me try it again. Here is my tak know Ulrich may not agree
> with me. To me, symbol versioning provides a way to reference and
> define a symbol h a version. For a reference to the symbol "foo"
> and version "ver1", it can only be resolved with the definition of
the symbol "foo" and version "ver1". There are 2 different versioned
> definitions:
>
> 1. The normal ve ned definition. The normal versioned definition of
> the symbol "foo" and version "ver1" can only resolve the referenc t; to the symbol "foo" and version "ver1".
> 2. The default versioned definition. The default versioned definition
of the symbol "foo" and version "ver1" can resolve the reference
> to the symbol "foo" and version "ver1" as well he reference to
> the symbol "foo" without any version. It can also be overriden by
> another default versioned nition or a definition without version.
>
> The symbol resolution should follow the normal ELF linker rule.
>
This description makes it seem as though the symbol version is really
> just part of the name (which is indeed approxima how we implement
> them). We could implement this by saying a symbol "foo" with version
> "ver1" is really a symbol d "foo-ver1". The default versioned
> definition of symbol "foo" with version "ver1" is simply two symbols
> which ar iased to the same value: "foo-ver1" and "foo".
>
> However, thinking about it, I see that you have glossed over some
issues in your point 2. You say that the default symbol can be
> overridden by a definition without a version. Let us that we have
> a reference to symbol (1) "foo" with version "ver1", and we have a
> reference to (2) "foo". Let us sa at in a shared library we have a
> definition of (3) "foo" with default version "ver1". References (1)
> and (2) will h resolve to definition (3), right? But now lets say
> that in a regular object file we have a definition of (4) "foo". ,
> according to your description, (4) overrides (3). Clearly (2) should
> resolve to (4). Should (1) also resolve t )? If (1) does resolve
> to (4), that implies that a default version (3) can somehow loan its
> version string to a s l (4) with the same name but no version.
> That seems strange.
I am enclosing a testcase here. For this one, (1) resolve (4). It
is not entirely unexpected. We can say
1. (1) resolves to (3).
2. Since (3) is the default definition, it can be o iden by (4).
Think about it, "a default version (3) can somehow loan its version
string to a symbol (4) with the same name no version." does make
sense since a default version can resolve an unversioned reference
and can be overriden by an unversi definition.
>
> We must also consider the case of (1), (2), and (3) as above, but now
> in a regular object file have (5) "foo" with version "ver1" but
> where (5) is not the default version. Presumably (1) should resolve
> to (5) hould (2) also resolve to (5)? If (2) does resolve to (5),
> that implies that a default version (3) can somehow loan it fault
> character to a symbol (5) with the same name and version, but which is
> not the default. That seems strange. ;
> Although these cases are more obvious when we consider regular files,
> I believe they can also occur when multip hared libraries define
> the same symbols. How does the Solaris linker behave with these
> cases? Are they covered i eir documentation?
>
> One way to resolve these confusions might be to ban overriding of
> symbols with default ve ns--to treat that case as a multiple
> definition error. I don't know what that would break.
>
It is a multiple def ion error today :-).
Here is what I got
# make
cc -g -O -c -o main1.o main1.c
cc -g -O -c -o ref1.o ref1.c
cc -g -O o ref2.o ref2.c
cc -shared -fPIC -o libfoo.so foo.c -Wl,--version-script,libfoo.map
cc -o test1 main1.o ref1.o ref2.o libfo -Wl,-rpath,.
./test1
foo, ver1: 30
foo: 30
cc -g -O -c -o main2.o main2.c
cc -o test2 main2.o ref1.o ref2.o libfoo.so -Wl ath,.
libfoo.so(*IND*+0x0): multiple definition of `foo@ver1'
main2.o:/user/hjl/bugs/gas/version11/main2.c:13: first defined e
collect2: ld returned 1 exit status
make: *** [test2] Error 1
--
H.J. Lu (hjl@valinux.com)
bug.tar.gz
- Follo:
html">Re: A patch for default version and archive
< LI>From: Ulrich Drepper
Re: A patch for default ver and archive