http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52388
--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2012-03-01 13:16:27 UTC --- Modifying acats/run_all.sh to pass -v to host_gnatmake when compiling widechr.adb, and to log the previous gcc call, showed: Generating support files...gcc -c cd300051.c ... gnatlink widechr.ali /usr/bin/ld: /mnt/scratch/objdir/gcc/testsuite/ada/acats/support/cd300051.o: Unknown mandatory EABI object attribute 44 /usr/bin/ld: failed to merge target specific data of file /mnt/scratch/objdir/gcc/testsuite/ada/acats/support/cd300051.o The bug is that it's invoking /usr/bin/ld rather than the one I installed privately and put in PATH before starting the gcc bootstrap and make check. This causes an inconsistency: cd300051.c is compiled and assembled in a PATH that refers to my new binutils under testing (I've verified that), but host_gnatlink tries to link things together using the old ld, which doesn't understand the new EABI attribute. I thought it did that due to the following fragment in acats/run_acats: > echo '#!/bin/sh' > host_gnatmake > echo PATH=`dirname $host_gnatmake`:'$PATH' >> host_gnatmake > echo unset ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_EXEC_PREFIX >> host_gnatmake > echo export PATH >> host_gnatmake > echo exec gnatmake '"$@"' >> host_gnatmake However, modifying run_acats to store the original PATH there (without all the adjustments for picking up the newly built compiler) didn't work. Even manually invoking the host gnatmake (in /usr/bin/) with a PATH that refers to my new binutils under testing, causes it to use the old ld in /usr/bin/. That feels like a bug to me. Anyway I'm relieved this didn't turn out to be a binutils bug.