RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...
David Daney
ddaney@avtrex.com
Fri Jul 29 03:36:00 GMT 2005
Daniel Jacobowitz wrote:
> On Thu, Jul 28, 2005 at 07:39:57PM -0700, David Daney wrote:
>
>>It seems that the linker thinks that any shared object that references
>>the magic _gp_disp symbol actually provides it. Since all mips objects
>>reference _gp_disp, ld thinks that all shared objects are required to
>>resolve all the other _gp_disp references. This causes all shared
>>objects specified with --as-needed to be deemed needed and get a
>>DT_NEEDED entry.
>>
>>The linker automagically resolves _gp_disp so this symbol should not
>>cause a shared library to be needed.
>>
>>I hope that makes at least a little sense.
>>
>>I suspect that the problem is mips specific as _gp_disp handling is mips
>>specific.
>
>
> Yes, you're probably right. I thought this sounded familiar, but
> couldn't find any references.
Here is my current plan:
$ mipsel-linux-readelf -s -D -W
/usr/local/mipsel-linux-3.4.3/lib/libc-2.3.3.so | grep SECTION
131 324: 0019bfb0 0 SECTION GLOBAL DEFAULT ABS _gp_disp
This seems to be where ld thinks that _gp_disp is defined by shared objects.
I can detect this special case in _bfd_mips_elf_add_symbol_hook() and
cause it to be ignored, thus solving the problem.
Does this seem like a reasonable course of action?
I am not sure how that dynamic symbol got into the shared objects in the
first place. I suppose if the proper solution was to not put it there
in the first place, I could fix that and rebuild the world. But that
would be much more work.
David Daney.
More information about the Binutils
mailing list