Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
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 21 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
Re: Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
On 06/22/2012 11:35 AM, Simon Baldwin wrote: Firstly, has anyone else encountered this or otherwise given it any thought? And secondly, any hints for practical fixes? What you effectively seem to be building is a cross-compiler from x86-glibc-A to x86-glibc-B. To run your tests, you want a machine that's running x86-glibc-B. I would have thought the best way to achieve this would be to run the tests in a chroot that is your sysroot. That's what gcc is compiling for. Andrew.
Re: Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
Andrew Haley a...@redhat.com writes: On 06/22/2012 11:35 AM, Simon Baldwin wrote: Firstly, has anyone else encountered this or otherwise given it any thought? And secondly, any hints for practical fixes? What you effectively seem to be building is a cross-compiler from x86-glibc-A to x86-glibc-B. To run your tests, you want a machine that's running x86-glibc-B. I would have thought the best way to achieve this would be to run the tests in a chroot that is your sysroot. That's what gcc is compiling for. That does not address the problem, at least not in any straightforward way. The problem is not running the tests, it's running the expect binary itself. Due to the setting of LD_LIBRARY_PATH before starting expect, expect is picking up the newly built libgcc_s.so. This fails in a rather obscure manner because expect is not actually linked against libgcc_s.so, but instead picks it up via the rather baroque way that glibc implements pthread_cancel. Logically, the only way this can be fixed is to not have LD_LIBRARY_PATH point into the newly built compiler when running expect. Of course LD_LIBRARY_PATH does need to be set within expect, so that the newly built compiler runs correctly. This is potentially a general problem. We should not be running any binaries installed on the host system with this setting of LD_LIBRARY_PATH. The only binaries we should run with LD_LIBRARY_PATH set are the ones that we just built. Therefore, I think it is a bug that we put TARGET_LIB_PATH into LD_LIBRARY_PATH in HOST_EXPORTS when gcc-bootstrap is true. Since GCC is linked with -static-libgcc -static-libstdc++, I think that we can get away with not doing that. Looking at the history this code seems to originate with the fix for http://gcc.gnu.org/PR17369 . This e-mail messages describes the problem: http://gcc.gnu.org/ml/gcc/2004-09/msg00209.html . Since we now link with -static-libgcc (and -static-libstdc++) I don't think this should be a problem any more. So I think we should simply try this patch (plus regenerate the top level Makefile.in, of course) and see what happens. Ian Index: Makefile.tpl === --- Makefile.tpl (revision 188349) +++ Makefile.tpl (working copy) @@ -228,9 +228,6 @@ HOST_EXPORTS = \ CLOOGINC=$(HOST_CLOOGINC); export CLOOGINC; \ LIBELFLIBS=$(HOST_LIBELFLIBS) ; export LIBELFLIBS; \ LIBELFINC=$(HOST_LIBELFINC) ; export LIBELFINC; \ -@if gcc-bootstrap - $(RPATH_ENVVAR)=`echo $(TARGET_LIB_PATH)$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ -@endif gcc-bootstrap $(RPATH_ENVVAR)=`echo $(HOST_LIB_PATH)$$$(RPATH_ENVVAR) | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); POSTSTAGE1_CXX_EXPORT = \
Re: Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
On 06/22/2012 03:27 PM, Ian Lance Taylor wrote: Andrew Haley a...@redhat.com writes: On 06/22/2012 11:35 AM, Simon Baldwin wrote: Firstly, has anyone else encountered this or otherwise given it any thought? And secondly, any hints for practical fixes? What you effectively seem to be building is a cross-compiler from x86-glibc-A to x86-glibc-B. To run your tests, you want a machine that's running x86-glibc-B. I would have thought the best way to achieve this would be to run the tests in a chroot that is your sysroot. That's what gcc is compiling for. That does not address the problem, at least not in any straightforward way. The problem is not running the tests, it's running the expect binary itself. Due to the setting of LD_LIBRARY_PATH before starting expect, expect is picking up the newly built libgcc_s.so. This fails in a rather obscure manner because expect is not actually linked against libgcc_s.so, but instead picks it up via the rather baroque way that glibc implements pthread_cancel. Well, yes, I realize that. My point is that you run expect on the host machine, and treat the virtual machine in the sysroot as the target, just as if you were cross-compiling. Which, in fact, you are. Andrew.
Re: Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
Andrew Haley a...@redhat.com writes: On 06/22/2012 03:27 PM, Ian Lance Taylor wrote: Andrew Haley a...@redhat.com writes: On 06/22/2012 11:35 AM, Simon Baldwin wrote: Firstly, has anyone else encountered this or otherwise given it any thought? And secondly, any hints for practical fixes? What you effectively seem to be building is a cross-compiler from x86-glibc-A to x86-glibc-B. To run your tests, you want a machine that's running x86-glibc-B. I would have thought the best way to achieve this would be to run the tests in a chroot that is your sysroot. That's what gcc is compiling for. That does not address the problem, at least not in any straightforward way. The problem is not running the tests, it's running the expect binary itself. Due to the setting of LD_LIBRARY_PATH before starting expect, expect is picking up the newly built libgcc_s.so. This fails in a rather obscure manner because expect is not actually linked against libgcc_s.so, but instead picks it up via the rather baroque way that glibc implements pthread_cancel. Well, yes, I realize that. My point is that you run expect on the host machine, and treat the virtual machine in the sysroot as the target, just as if you were cross-compiling. Which, in fact, you are. In a general sense, sure. But in a specific sense, it's the GCC Makefiles that are setting LD_LIBRARY_PATH before invoking expect, and they are doing that before any possible chroot could be set up. I suppose one could reconcile these two viewpoints by observing that in order to see this problem Simon must be bootstrapping. So the bug is that we do not support a cross-compilation in which the cross-compiler is bootstrapped. And while that is of course impossible in general, it is entirely possible in the case of a cross-compiler to a newer version of glibc. Ian
