Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc

[Simon Baldwin]

I've recently encountered a gcc testsuite issue that is caused by the
libgcc_s in the built compiler being incompatible with, but the same
architecture as, the host's libc.  I'm not sure what the right fix is,
so I'm looking for ideas.

I build gcc-4.7 for x86 on an x86 host.  The bootstrap compiler is not
the host compiler, and sysroot options link the built gcc-4.7 against
an alternative libc, one that is newer than the host's libc.

Within gcc, to support bootstrap builds the top level makefile sets
LD_LIBRARY_PATH to encompass ./gcc and ./prev-gcc, and passes that
setting to both build and check targets.  The build creates a new
libgcc_s in ./gcc, and when 'make check' executes expect via runtest
this new libgcc_s is visible to the expect binary.

Expect is threaded, and calls pthread_exit, which calls
pthread_cancel_init, which dlopen's libgcc_s.  Because of
LD_LIBRARY_PATH, the host libc finds the new libgcc_s from the gcc
build.  In my case they're not compatible.  The new libgcc_s was built
against a non-host libc that is newer than the host's libc and so
dlopen fails to find a versioned symbol.  libc aborts the expect
process:

  libgcc_s.so.1 must be installed for pthread_cancel to work
  Aborted

Several check targets refuse to run -- though bizarrely, not actually
fail the testsuite(!) --  because expect invoked by 'runtest
--version' aborts:

  /bin/sh: line 10: 21052 Aborted                 /bin/sh -c "$runtest
--version" > /dev/null 2>&1
  WARNING: could not find `runtest'

Firstly, has anyone else encountered this or otherwise given it any
thought?  And secondly, any hints for practical fixes?

Thx.

--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902