Re: R_PPC_LOCAL24PC c++ linking problems with current binutils

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jul 20, 1999 at 12:17:08PM +1000, Geoff Keating wrote:
> OK, I see it.
> 
> The problem is that the following is happening:
> 
> 1. g++ is defining the symbol 
>  '__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
>    (in demangled form, which I'll just call `...' from now on :-)
>    weak in a linkonce section.
> 2. In libstdc++.so, the symbol is not defined weak.
> 3. In the same linkonce section, there is 'bl ...@local'.  The @local
>    is because it's a recursive call.
> 4. ld finds the strong definition, in the shared object.
> 5. The symbol is not therefore defined locally, and linking fails.
>   
> I assume ld is correct in emitting the linkonce section even though
> it will actually be using the shared object symbol.  I may be wrong.
> Certainly it doesn't seem to make much sense to do this.
> 
> Other fixes would be:
> (i) define the libstdc++ symbol weak, and/or
> (ii) don't use @local on weak symbols and/or 
> (iii) make @local relocs point to the symbol defined in this object
> whether or not there is a stronger definition elsewhere.

As I prepare to expose my underlying ignorance of how binutils works...

It seems to me that we know before we try to relocate anything inside
of the linkonce section whether or not we will be using this
section - either we do, or we should fairly easily be able to
determine.

If this is the case, then is it possible to simply not perform the
relocation in this case?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/