This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc testsuite, LD_LIBRARY_PATH, and a new libgcc_s that is incompatible with the host libc
Andrew Haley <aph@redhat.com> writes:
> On 06/22/2012 03:27 PM, Ian Lance Taylor wrote:
>> Andrew Haley <aph@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