mipsel-linux build: not a dynamic executable

[Rob Landley]

On Sunday 11 February 2007 10:46 pm, Erik Andersen wrote:
> On Sun Feb 11, 2007 at 08:21:51PM -0500, Rob Landley wrote:
> > On Monday 05 February 2007 12:17 am, Mike Frysinger wrote:
> > > On Monday 05 February 2007, Doug the RockRat wrote:
> > > > libs ldd says are "not a dynamic executable"
> > > 
> > > dont run the host ldd on the cross-compiled files ... it wont work even 
a 
> > > little bit
> > > -mike
> > 
> > Did anyone ever make any progress on cross-compiling uClibc's ldd?
> 
> Umm, cross-compiling uClibc's ldd works just fine and has worked
> just fine for years and years.

Just following up on
http://uclibc.org/lists/uclibc/2006-December/016988.html

> Now before I go off mentioning 
> buildroot -- I realize you hate buildroot and refuse to look at
> how it does things, etc, etc, etc, so you needn't bother with
> your usual reply as about how your stuff is so much better.

Not hate, just doesn't match what I'm doing.

> Anyway, moving on to the relevant bits.  A quick glance at
> buildroot/toolchain/uClibc/uclibc.mk reveals that, no, the utils
> are not automatically built when you build uClibc.  It requires a
> separate step (i.e. once you have completely built and installed
> your shiny new toolchain).  Something along the lines of:
> 
> make -C CROSS="$(CROSS)" CC="$(CC)" PREFIX="$(PREFIX)" utils install_utils

sh-3.1$ make V=1 CROSS=armv4l- CC=cc 
PREFIX=/home/landley/firmware/firmware/build/cross-compiler-armv4l/ utils
make CROSS="armv4l-" CC="cc" -C utils
cc -c ../utils/readelf.c -o ../utils/readelf -include ../include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -mlittle-endian -fno-builtin -nostdinc -I../include -I. -fsigned-char -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fstrict-aliasing -I../libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I../libpthread/linuxthreads.old/sysdeps/arm -I../libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I../libpthread/linuxthreads.old/sysdeps/pthread -I../libpthread/linuxthreads.old -I../libpthread -I/usr/src/linux/include/ -isystem /usr/lib/gcc/i486-linux-gnu/4.0.3/include -DNDEBUG -DNOT_IN_libc -B../lib -Wl,-rpath-link,../lib
cc ../utils/readelf.c  -o ../utils/readelf -include ../include/libc-symbols.h  -Wall -Wstrict-prototypes -fno-strict-aliasing  -mlittle-endian  -fno-builtin -nostdinc -I../include -I. -fsigned-char  -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fstrict-aliasing   -I../libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I../libpthread/linuxthreads.old/sysdeps/arm -I../libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I../libpthread/linuxthreads.old/sysdeps/pthread -I../libpthread/linuxthreads.old -I../libpthread -I/usr/src/linux/include/ -isystem /usr/lib/gcc/i486-linux-gnu/4.0.3/include -DNDEBUG -DNOT_IN_libc  -B../lib -Wl,-rpath-link,../lib
cc1: error: invalid option 'little-endian'
make[1]: *** [../utils/readelf] Error 1
make: *** [utils] Error 2
sh-3.1$                       

Although armv4l-gcc understands little endian, host gcc does not, so 
passing -mlittle-endian to $CC (as the January 30 snapshot is doing) makes it 
go "boing".  I can upgrade if you think it'd help, but you said this has 
worked for years so apparently I'm doing something wrong.

> and lo and behold, a set of nicely cross compiled apps such as ldd
> will magically be installed, compiled with the specified toolchain.

You've done this for armv4l?

> > Or am I doing it wrong?
> 
> I think you must be doing it wrong...

I think I'm doing it wrong too.  I just don't know what.

>  -Erik

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery