Hi! Actually this bug is with glibc-2.5, resp glibc-ports-2.5. We're cross compiling from i686 to ixp420 in big endian mode and it's not possible to produce working dynamically linked nptl/eabi executables. The toolchain we use is: gcc-4.1.1 (release) plus http://gcc.gnu.org/bugzilla/attachment.cgi?id=12542&action=view glibc-2.5 (relasee) plus http://sourceware.org/ml/libc-ports/2006-10/msg00024.html binutils-2.17 (release) Kernel is: 2.8.18 (release) plus BSP patches, with CONFIG_AEABI=y CONFIG_OABI_COMPAT=y We boot into oabi userland (gcc-4.0.3/glibc-2.3.6/linuxthread) and do a chroot into the eabi/nptl environment (proc and sysfs are mounted prior to chroot) root@ixp425:/mnt> chroot . ./main : error while loading shared libraries: /e/l///libc.so.6piinvalid ELF heade/li//l/bc./o.6ipibsb Even copying the ld-2.5.so to /lib and the rest to /lib/tls. and omitting the chroot brings no difference. A statically linked program works btw: root@ixp425:/mnt> chroot . ./main_static Hello World!
Created attachment 1429 [details] exmaple program to trigger the bug Just a simple hello world app to trigger the bug
Created attachment 1431 [details] compiler and strace output from dynamically linked app This is the compiler (gcc -v) and strace output from the test app linked dynamically.
Created attachment 1433 [details] compiler and strace output from statically linked app This is the compiler (gcc -v) and strace output from the test app linked statically.
Thanks to Daniel Jacobowitz for the helpfull hints. The gcc patch was indeed not complete. The preprocessor was defining __ARMEL__ although it supposed to be a big endian one. For completeness this is the link to the improved gcc patch, which fixes the faulty behaviour: http://gcc.gnu.org/bugzilla/attachment.cgi?id=12705&action=view