building multilibs broken

Dave Murphy
Sun May 6 13:18:00 GMT 2007


I've been bitten by a similar issue to this one

The toolchain I'm building is arm-eabi

arm-eabi-gcc -print-multi-lib says


The problem was noticed because the thumb libc  was missing  
__libc_init_array but the arm libraries weren't. Adding a #error to 
init.c stopped the build  at this point.
Making all in misc
gmake[8]: Entering directory 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"1.15.0\" -DPACKAGE_STRING=\"newlib\ 1.15.0\" 
-I../../../../../../newlib-1.15.0/newlib/libc/misc -O2 -D__NO_SYSCALLS__ 
-fno-builtin      -O2 -DREENTRANT_SYSCALLS_PROVIDED   -mthumb -c -o 
lib_a-init.o `test -f 'init.c' || echo 
../../../../../../newlib-1.15.0/newlib/libc/misc/init.c:17:2: error: 
#error What the ...?
gmake[8]: *** [lib_a-init.o] Error 1

$ find ./ -name targ-include

Exactly the same symptoms as Shaun was experiencing.

The really weird thing about this is that it doesn't happen on my 
msys/mingw build or a debian build but breaks on a freeBSD system. 
Another user did report similar symptoms when trying to insert the 
Digital Mars compiler into devkitARM and I believe that may be related.

Jeff said that there should only be one targ-include but that appears 
not to be the case or at least targ-include is being copied to several 
places in the build tree.

the -isystem path appears to be coming from the top level configure 
where it sets FLAGS_FOR_TARGET

-isystem $$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem 

I'd hazard a guess that $(TARGET_SUBDIR) isn't set when the multilib 
dirs are being configured. Unfortunately I'm a bit lost atm, does anyone 
have any suggestions what I might need to patch to get the correct 
-isystem path?


More information about the Newlib mailing list