Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

[dank]

ddaney wrote:
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
> and whenever I compile even the simplest hello-world.c libgcc_s.so is
linked.


Just curious -- how did you build your cross-compiler?
Do toolchains built by crosstool have this problem?
(I'm away from home, or I'd check.)
- Dan

Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

[David Daney]

dank@kegel.com wrote:
> ddaney wrote:
> 
>>I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
>>and whenever I compile even the simplest hello-world.c libgcc_s.so is
> 
> linked.
> 
> 
> Just curious -- how did you build your cross-compiler?

I have a bunch of rpm build scripts, but they pretty much just do a 
standard configure and make.

I never do a clean build of glibc and gcc in the same pass so I don't 
have the chicken and egg glibc header file problem.

> Do toolchains built by crosstool have this problem?

I have not checked, but I suspect so.

The problem is in the linker.  I am trying to fix it, but ld is an ugly 
beast.

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.

David Daney

Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

[David Daney]

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.

Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux crosscompiler...

[Alan Modra]

On Thu, Jul 28, 2005 at 08:36:11PM -0700, David Daney wrote:
> 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?

Yes.  That does cost a strcmp on every symbol in every input file
though.  It's somewhat better to do strcmp once on every global symbol
in adjust_dynamic_symbol.  See elf32-ppc.c handling of _SDA_BASE_.
Even better would be a hash lookup in something run before
adjust_dynamic_symbol, say, always_size_sections.  I didn't think of
that when I added the ppc code.

> 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

It would be good if new shared objects don't have this bug.  Forcing the
sym local should cure it.

> and rebuild the world.  But that 
> would be much more work.
> 
> David Daney.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre