[Bug ada/52388] binutils-2.21 and newer break ACATS on arm-linux-gnueabi due to widechr compile failure

["mikpe at it dot uu.se" <gcc-bugzilla at gcc dot gnu dot org>]

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.