Re: Cross-compiler builds but results fail in crt1.o ...?

[Paul Smith <paul at mad-scientist dot net>]

Hi all; no responses to this so far.  Is it just too old a release to
bother with, and/or does no one have any thoughts about it or ideas of
where to look?  Cheers!

On Tue, 2012-04-17 at 16:42 -0400, Paul Smith wrote:
> Anyone have any thoughts for me about where to start poking to try to
> resolve (or at least get more details about) this issue?
> 
> Thanks!
> 
> On Thu, 2012-04-12 at 19:05 -0400, Paul Smith wrote:
> > Hi all.
> > 
> > I've created a cross-compiler environment that appears to work well for
> > the most part, but clearly there's something not right with it.  I've
> > poked and prodded it for a while but I can't come up with anything.
> > 
> > I'm running the compiler on GNU/Linux Intel and my cross-environment is
> > also GNU/Linux Intel, but a different version.  I have built the
> > compiler using a Canadian cross procedure, where the host is GNU/Linux
> > RHEL5 Intel 32bit and the target is a generic GNU/Linux Intel system,
> > supporting both 32 and 64bit output.
> > 
> > The bad news is I'm using GCC 4.2.4 and binutils 2.18.  Unfortunately
> > it's not practical for me to upgrade right now (next release...).  I
> > know that it's possible to use these versions because I was using them
> > before, with an incorrect compiler build procedure that didn't have the
> > problem below (unfortunately it ALSO didn't create libstdc++.so with
> > version information, due to not detecting GNU ld etc., which meant that
> > I couldn't link some 3rdparty C++ shared libraries... hence this attempt
> > to rebuild the compiler "correctly").
> > 
> > When I run the compiler I'm using --sysroot pointing at a Red Hat EL 6
> > sysroot containing both 32bit and 64bit libraries in typical multilib
> > config.
> > 
> > I can give lots of gory details, but I'm hoping someone can help me
> > narrow down my search before I get too deep.  See if the behavior below
> > creates any suspicions:
> > 
> > Here's a simple program:
> > 
> >         struct foo { char app[128]; };
> >         int main(void) { struct foo x = {0}; return 0; }
> > 
> > The trick here is the struct needs to contain an array; simple integers
> > don't cause any problems; you'll see why below.  If I build this as a
> > 64bit program (the default) then it works (FWIW I'm building this on
> > RHEL 6.2):
> > 
> >         $ x86_64-generic-linux-gnu-gcc --sysroot=/cc/sysroot -o foo /tmp/foo.c
> >         $ LD_LIBRARY_PATH=/cc/sysroot/lib64 ./foo
> > 
> > But, if I build it as a 32bit application, then it dumps core
> > immediately in some internal code:
> > 
> >         $ x86_64-generic-linux-gnu-gcc --sysroot=/cc/sysroot -m32 -o foo /tmp/foo.c
> >         $ LD_LIBRARY_PATH=/cc/sysroot/lib ./foo
> >         Segmentation fault
> >         
> >         $ LD_LIBRARY_PATH=/cc/sysroot/lib gdb ./foo
> >             ...
> >         Program received signal SIGSEGV, Segmentation fault.
> >         0x080496e0 in ?? ()
> >         (gdb) bt
> >         #0  0x080496e0 in ?? ()
> >         #1  0x00127cc6 in __libc_start_main () from /cc/sysroot/lib/libc.so.6
> >         #2  0x08048301 in _start ()
> > 
> > It also works if I build it 32bit using c++ with static libstdc++... but
> > not dynamic C++!  Weird!
> > 
> > If I change the code to this:
> > 
> >         struct foo { char app[128]; };
> >         int main(void) { struct foo x; strcpy(x.app, "foo"); return 0; }
> > 
> > then it still dumps core but the backtrace is slightly more interesting:
> > 
> > (gdb) bt
> > #0  0x07f364ef in ?? ()
> > #1  0x0804964f in memcpy@@GLIBC_2.0 ()
> > #2  0x08048396 in main ()
> > 
> > If I generate a linker map looking for memcpy() I see this:
> > 
> >         .dynbss        0x0000000008049620       0x46 /cc/sysroot/usr/lib/../lib/crt1.o
> >                        0x0000000008049620                memcpy@@GLIBC_2.0
> > 
> > And crt1.o looks OK:
> > 
> >         $ file /cc/sysroot/usr/lib/crt1.o
> >         /cc/sysroot/usr/lib/crt1.o: ELF 32-bit LSB relocatable, Intel 80386,
> >           version 1 (SYSV), for GNU/Linux 2.6.18, not stripped
> > 
> > Looking at the rest of the linker map I don't see any references to any
> > objects or libraries that aren't either (a) in my compiler's directory,
> > like crtbegin.o etc., or (b) in the sysroot directories.  Sooo, I'm a
> > bit stumped.  Seems like something is mismatched somewhere...
> > 
> > Any idea where to look?