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
