This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: How to build/test glibc with new gcc
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 17 Jul 2015 16:18:47 -0300
- Subject: Re: How to build/test glibc with new gcc
- Authentication-results: sourceware.org; auth=none
- References: <55A9324B dot 2090503 at arm dot com> <55A93549 dot 8090703 at linaro dot org> <55A93DFB dot 60003 at redhat dot com> <55A93F2A dot 7090207 at linaro dot org> <55A94856 dot 3060503 at redhat dot com>
On 17-07-2015 15:24, Carlos O'Donell wrote:
> On 07/17/2015 01:45 PM, Adhemerval Zanella wrote:
>>
>>
>> On 17-07-2015 14:40, Carlos O'Donell wrote:
>>> On 07/17/2015 01:03 PM, Adhemerval Zanella wrote:
>>>> On 17-07-2015 13:50, Szabolcs Nagy wrote:
>>>>> i'm wondering what's the official way to build glibc with new gcc.
>>>>>
>>>>> the documentation about building glibc assumes that the host
>>>>> compiler is used when doing a native build, but if gcc is installed
>>>>> at some prefix path, then the tests don't use the right libraries:
>>>>>
>>>>> they use libgcc_s.so.1 and libstdc++.so.6 of the host (or fail
>>>>> when the host does not have these).
>>>>>
>>>>> Using LD_LIBRARY_PATH does not work as the tests override the
>>>>> library path, but i assume this can be solved by either adding
>>>>> -Wl,-rpath=/gcc/prefix/lib to the LDFLAGS of the tests or
>>>>> copying the compiler runtime into the build path:
>>>>>
>>>>> export PATH="/path/to/gcc-prefix/bin:$PATH"
>>>>> cp -a /path/to/gcc-prefix/lib*/*.so* .
>>>>> /path/to/glibc-src/configure --prefix=/usr
>>>>> make -j
>>>>> make check
>>>>>
>>>>> is there a cleaner way to do it?
>>>>
>>>> I used to apply a modified version of [1], configure and install GCC
>>>> in a different folder than system one. Unfortunately I think Meissner
>>>> patch did not land in upstream.
>>>>
>>>> [1] https://gcc.gnu.org/ml/gcc-patches/2012-05/msg02097.html
>>>>
>>>
>>> Don't sysroot'd builds solve this problem?
>>>
>>
>> As described in patch:
>>
>> "it is not a --sysroot type of release, because if a given library is
>> not provided, it will default to using the host libraries on the system."
>>
>> But yeah, this might lead to some incompatibilities with symbol versioning
>> (specially for C++ programs), but the idea is just have the GCC linking
>> against its news libraries and using the system libraries as default.
>
> Is that a problem with your sysroot setup then?
Not really, back when I used to use this patch the idea was to no use sysroot.