RFH: libgcc_s.so being unnecessarily linked for mipsel-linux cross compiler...

RFH: libgcc_s.so being unnecessarily linked for mipsel-linux cross compiler...

[David Daney]

I am not sure if this is a GCC problem or a binutils problem.

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.

When I do the same thing natively on my i686/FC3, libgcc_s.so is not linked.

If if explicitly pass -static-libgcc to the cross compiler I do not need 
libgcc_s.so (as would be expected).

As you can see from the transcript below libgcc_s is being linked with 
--as-needed.

Also you can see that neither hello-world.o nor my libc-2.3.3.so have 
any undefined symbols that would be satisfied by libgcc_s.so.

Any ideas about what is going on here?


[daney@dl2 junk]$ cat hello-world.c
#include <stdio.h>

int main(int argc, char *argv[])
{
         puts("Hello World!");
         return 0;
}
[daney@dl2 junk]$ mipsel-linux-gcc -v -o hello-world hello-world.c
Reading specs from 
/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --target=mipsel-linux 
--with-sysroot=/usr/local/mipsel-linux-3.4.3 --with-arch=mips32 
--with-float=soft --enable-languages=c,c++,java 
--prefix=/usr/local/mipsel-linux-3.4.3 --with-system-zlib 
--disable-java-awt --without-x --disable-jvmpi
Thread model: posix
gcc version 3.4.3
  /usr/local/mipsel-linux-3.4.3/libexec/gcc/mipsel-linux/3.4.3/cc1 
-quiet -v hello-world.c -quiet -dumpbase hello-world.c -march=mips32 
-msoft-float -auxbase hello-world -version -o /tmp/cclyJCDa.s
ignoring nonexistent directory 
"/usr/local/mipsel-linux-3.4.3/usr/local/include"ignoring nonexistent 
directory 
"/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/../../../../mipsel-linux/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/include
  /usr/local/mipsel-linux-3.4.3/usr/include
End of search list.
GNU C version 3.4.3 (mipsel-linux)
         compiled by GNU C version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64141
 
/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/../../../../mipsel-linux/bin/as 
-EL -no-mdebug -32 -march=mips32 -v -KPIC -o /tmp/ccylpyDd.o /tmp/cclyJCDa.s
GNU assembler version 2.16.1 (mipsel-linux) using BFD version 2.16.1
  /usr/local/mipsel-linux-3.4.3/libexec/gcc/mipsel-linux/3.4.3/collect2 
--eh-frame-hdr -EL -dynamic-linker /lib/ld.so.1 -o hello-world 
/usr/local/mipsel-linux-3.4.3/usr/lib/crt1.o 
/usr/local/mipsel-linux-3.4.3/usr/lib/crti.o 
/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/crtbegin.o 
-L/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3 
-L/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/../../../../mipsel-linux/lib 
-L/usr/local/mipsel-linux-3.4.3/lib 
-L/usr/local/mipsel-linux-3.4.3/usr/lib /tmp/ccylpyDd.o -lgcc 
--as-needed -lgcc_s --no-as-needed -rpath-link 
/usr/local/mipsel-linux-3.4.3/lib:/usr/local/mipsel-linux-3.4.3/usr/lib 
-lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/local/mipsel-linux-3.4.3/lib/gcc/mipsel-linux/3.4.3/crtend.o 
/usr/local/mipsel-linux-3.4.3/usr/lib/crtn.o

[daney@dl2 junk]$ readelf -d hello-world

Dynamic section at offset 0x15c contains 26 entries:
   Tag        Type                         Name/Value
  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
  0x00000001 (NEEDED)                     Shared library: [libc.so.6]


[daney@dl2 junk]$ mipsel-linux-gcc -c hello-world.c
[daney@dl2 junk]$ mipsel-linux-nm hello-world.o
          U _gp_disp
00000000 T main
          U puts

[daney@dl2 junk]$ mipsel-linux-nm 
/usr/local/mipsel-linux-3.4.3/lib/libc-2.3.3.so | grep 'U '
          U _dl_argv@@GLIBC_PRIVATE
          U _dl_catch_error@@GLIBC_PRIVATE
          U _dl_check_map_versions@@GLIBC_PRIVATE
          U _dl_debug_printf@@GLIBC_PRIVATE
          U _dl_debug_state@@GLIBC_PRIVATE
          U _dl_dst_count@@GLIBC_PRIVATE
          U _dl_dst_substitute@@GLIBC_PRIVATE
          U _dl_get_origin@@GLIBC_PRIVATE
          U _dl_init@@GLIBC_PRIVATE
          U _dl_lookup_symbol@@GLIBC_PRIVATE
          U _dl_lookup_symbol_skip@@GLIBC_PRIVATE
          U _dl_lookup_versioned_symbol@@GLIBC_PRIVATE
          U _dl_lookup_versioned_symbol_skip@@GLIBC_PRIVATE
          U _dl_map_object_deps@@GLIBC_PRIVATE
          U _dl_map_object@@GLIBC_PRIVATE
          U _dl_mcount@@GLIBC_2.2
          U _dl_out_of_memory@@GLIBC_PRIVATE
          U _dl_relocate_object@@GLIBC_PRIVATE
          U _dl_signal_error@@GLIBC_PRIVATE
          U _dl_start_profile@@GLIBC_PRIVATE
          U _dl_unload_cache@@GLIBC_PRIVATE
          U __libc_enable_secure@@GLIBC_PRIVATE
          U __libc_stack_end@@GLIBC_2.2
          U _r_debug@@GLIBC_2.0
          U _rtld_global@@GLIBC_PRIVATE

Thanks,
David Daney

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

[H. J. Lu]

On Thu, Jul 28, 2005 at 12:48:31PM -0700, David Daney wrote:
> I am not sure if this is a GCC problem or a binutils problem.
> 
> 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.
> 
> When I do the same thing natively on my i686/FC3, libgcc_s.so is not linked.
> 
> If if explicitly pass -static-libgcc to the cross compiler I do not need 
> libgcc_s.so (as would be expected).
> 
> As you can see from the transcript below libgcc_s is being linked with 
> --as-needed.
> 
> Also you can see that neither hello-world.o nor my libc-2.3.3.so have 
> any undefined symbols that would be satisfied by libgcc_s.so.
> 
> Any ideas about what is going on here?
> 

Does your glibc need libgcc_s.so? Can you try the current binutils?


H.J.

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

[David Daney]

H. J. Lu wrote:
> On Thu, Jul 28, 2005 at 12:48:31PM -0700, David Daney wrote:
> 
>>I am not sure if this is a GCC problem or a binutils problem.
>>
>>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.
>>
>>When I do the same thing natively on my i686/FC3, libgcc_s.so is not linked.
>>
>>If if explicitly pass -static-libgcc to the cross compiler I do not need 
>>libgcc_s.so (as would be expected).
>>
>>As you can see from the transcript below libgcc_s is being linked with 
>>--as-needed.
>>
>>Also you can see that neither hello-world.o nor my libc-2.3.3.so have 
>>any undefined symbols that would be satisfied by libgcc_s.so.
>>
>>Any ideas about what is going on here?
>>
> 
> 
> Does your glibc need libgcc_s.so? Can you try the current binutils?
> 

I don't think so:


[daney@dl2 junk]$ readelf -d /usr/local/mipsel-linux-3.4.3/lib/libc-2.3.3.so

Dynamic section at offset 0x14c contains 28 entries:
   Tag        Type                         Name/Value
  0x00000001 (NEEDED)                     Shared library: [ld.so.1]
  0x0000000e (SONAME)                     Library soname: [libc.so.6]
  0x0000000c (INIT)                       0x15790

[daney@dl2 junk]$ readelf -d /usr/local/mipsel-linux-3.4.3/lib/ld-2.3.3.so

Dynamic section at offset 0xec contains 22 entries:
   Tag        Type                         Name/Value
  0x0000000e (SONAME)                     Library soname: [ld.so.1]
  0x00000004 (HASH)                       0x1c4

As far as I can tell none of the undefined symbols in libc.so.6 are 
satisfied by libgcc_s.so.

Do you know of a patch to binutils since 2.16.1 that would fix the problem?

David Daney

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

[James E Wilson]

On Thu, 2005-07-28 at 12:48, David Daney wrote:
> Also you can see that neither hello-world.o nor my libc-2.3.3.so have 
> any undefined symbols that would be satisfied by libgcc_s.so.

It looks like you forgot to check the crt*.o files for undefined
references.

If the gcc/glibc toolchain wasn't built the optimal way, it is possible
for crtbegin.o to have register_frame_info and deregister_frame_info
calls for C++ EH unwinding which would require libgcc always.

If built the optimal way, then the gcc/glibc toolchain will use an
alternate method for C++ EH unwinding that does not require crtbegin.o
support and hence does not require libgcc.  This is why the x86 FC3 is
OK.

See the USE_PT_GNU_EH_FRAME stuff in gcc/crtstuff.c.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

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

[Richard Henderson]

On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> On Thu, 2005-07-28 at 12:48, David Daney wrote:
> > Also you can see that neither hello-world.o nor my libc-2.3.3.so have 
> > any undefined symbols that would be satisfied by libgcc_s.so.
> 
> It looks like you forgot to check the crt*.o files for undefined
> references.

Alternately, it's not impossible that --as-needed is broken
for mips binutils.


r~

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

[Greg Schafer]

On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:

> It looks like you forgot to check the crt*.o files for undefined
> references.
> 
> If the gcc/glibc toolchain wasn't built the optimal way, it is possible
> for crtbegin.o to have register_frame_info and deregister_frame_info
> calls for C++ EH unwinding which would require libgcc always.
> 
> If built the optimal way, then the gcc/glibc toolchain will use an
> alternate method for C++ EH unwinding that does not require crtbegin.o
> support and hence does not require libgcc.  This is why the x86 FC3 is
> OK.
> 
> See the USE_PT_GNU_EH_FRAME stuff in gcc/crtstuff.c.

Jim, I'd be grateful if you could please clarify what you mean by the
"optimal way". I assume you mean whether the initial "bootstrap" cross
compiler was built against Glibc headers or not. ie:

 Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal 
 Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal

It seems to me that most Glibc targets can be built either way, but some
need a little coaxing, Mips can certainly be built either way "out of the
box". AFAICT, IA64 is the only target that cannot be built without access to
the Glibc headers.

Clearly, optimal is best :-)

Thanks for any clarification.

Regards
Greg

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

[James E Wilson]

On Thu, 2005-07-28 at 16:58, Greg Schafer wrote:
>  Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal 
>  Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal

This is basically what I meant, but I don't want to get in a debate
about what is optimal and what isn't.  Maybe I should have used a
different word.

Anyways, I regard Dan Kegel's crosstools as the best source of info on
doing linux cross toolchain builds.  His scripts get this right, and
aren't very hard to use.  There are also other ways of getting the same
result.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

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

[H. J. Lu]

On Thu, Jul 28, 2005 at 01:54:40PM -0700, David Daney wrote:
> 
> Do you know of a patch to binutils since 2.16.1 that would fix the problem?
> 

I remember there were some patches for as needed. But I don't know if
they are in 2.16.1 or not.


H.J.

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

[Mike Frysinger]

On Thursday 28 July 2005 08:22 pm, James E Wilson wrote:
> On Thu, 2005-07-28 at 16:58, Greg Schafer wrote:
> >  Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal
> >  Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal
>
> This is basically what I meant, but I don't want to get in a debate
> about what is optimal and what isn't.  Maybe I should have used a
> different word.
>
> Anyways, I regard Dan Kegel's crosstools as the best source of info on
> doing linux cross toolchain builds.  His scripts get this right, and
> aren't very hard to use.  There are also other ways of getting the same
> result.

Dan's crosstool installs glibc headers before attempting any gcc steps since 
afaik any other method is unsupported by the gcc team
-mike

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

[David Daney]

H. J. Lu wrote:
> On Thu, Jul 28, 2005 at 01:54:40PM -0700, David Daney wrote:
> 
>>Do you know of a patch to binutils since 2.16.1 that would fix the problem?
>>
> 
> 
> I remember there were some patches for as needed. But I don't know if
> they are in 2.16.1 or not.

HEAD also seems to fail.

David Daney.

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

[Richard Sandiford]

David Daney <ddaney@avtrex.com> writes:
> 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.

FWIW, I'm seeing the same thing with a similar native setup.
I hope to have a look at it soon.

Richard