This is the mail archive of the binutils@sourceware.cygnus.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: [new test case jluu@mainsoft.com: Re: Possible linker problem]



Hi Ian and H.J.

Some clarifications, (looking at the new code will help further).

In the case I am reporting, C++ is not involved (finally, after more work on
pinning it down).

The executable is referencing a symbol in the shared library with no intent
to override (declared as external int).

The shared library is linked with Bsymbolic.

The result is that the said symbol also becomes defined in the executable,
so we have 2 symbols with the same name and the confusion that results.

I believe that solving this will solve the C++ RTTI crash in the first test
case.

Regards
Jose



-----Message d'origine-----
De : Ian Lance Taylor <ian@zembu.com>
À : hjl@lucon.org <hjl@lucon.org>
Cc : binutils@sourceware.cygnus.com <binutils@sourceware.cygnus.com>;
jluu@mainsoft.com <jluu@mainsoft.com>
Date : Tuesday, March 14, 2000 7:06 PM
Objet : Re: [jluu@mainsoft.com: Re: Possible linker problem]


>   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.
>
>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.
>
>Ian
>

t143n.tar.gz


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