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
