[jluu@mainsoft.com: Re: Possible linker problem]

[H . J . Lu]

On Tue, Mar 14, 2000 at 10:02:04AM -0800, Ian Lance Taylor wrote:
>    Date: Tue, 14 Mar 2000 09:55:09 -0800
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    I know the problem. As I said, it is a combination of C++, -Bsymbolic
>    and ia32 ABI. We cannot change ia32 ABI. It will be hard to change
>    C++. The only feasible thing is -Bsymbolic. Ian, we can change
>    ld such that
> 
>    1. Don't apply -Bsymbolic to any data objects which are generated
>    by compiler, like any symbols started with "__". Or
>    2. Use can provided a list of symbols which we don't do -Bsymbolic on.
> 
>    I like #1 and we can have a switch to turn it on and off.
> 
> I don't know the actual bug, so I don't see how I can comment.

Oops. I forgot it.  I enclosed a testcase here.
> 
> I can't imagine any way that I would think that choice number 1 was
> correct.  -Bsymbolic is clearly defined.  I don't think we should
> change it.
> 
> -Bsymbolic does not prevent you from referring to symbols which are
> not defined in the shared library.  I assume you have a case where a
> symbol is defined in a shared library, but you want to permit it to be
> overridden.  You should not be using -Bsymbolic in such a case.  You
> need the more precise control over symbol visibility that you can get
> by using a version script.  In other words, choice 2 is already
> available.

Not a bad idea.


H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t143.tar.gz
Type: application/x-gzip
Size: 73967 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20000314/06813f2c/attachment.bin>