glibc2.32 build error for powerpc64-unknown-linux-gnu
Chris Packham
Chris.Packham@alliedtelesis.co.nz
Mon Sep 7 00:04:54 GMT 2020
On 6/09/20 9:35 pm, Chris Packham wrote:
>
> On 5/09/20 1:33 am, Adhemerval Zanella wrote:
>>
>> On 03/09/2020 17:58, Chris Packham wrote:
>>> On 3/09/20 10:53 pm, Adhemerval Zanella wrote:
>>>> On 03/09/2020 06:09, Chris Packham wrote:
>>>>> On 3/09/20 2:39 pm, Chris Packham wrote:
>>>>>> On 3/09/20 9:14 am, Chris Packham wrote:
>>>>>>> On 3/09/20 2:20 am, Adhemerval Zanella wrote:
>>>>>>>> On 02/09/2020 05:05, Chris Packham wrote:
>>>>>>>>> On 2/09/20 7:40 am, Adhemerval Zanella wrote:
>>>>>>>>>> On 30/08/2020 07:40, Chris Packham via Libc-help wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> crosstool-ng was recently updated to add glibc-2.32. We're
>>>>>>>>>>> seeing
>>>>>>>>>>> the
>>>>>>>>>>> following error building for powerpc64
>>>>>>>>>>>
>>>>>>>>>>> [ALL ] In file included from
>>>>>>>>>>> ../sysdeps/powerpc/powerpc32/power4/multiarch/wordcopy-ppc32.c:26,
>>>>>>>>>>>
>>>>>>>>>>> [ALL ] from
>>>>>>>>>>> ../sysdeps/powerpc/powerpc64/multiarch/wordcopy-ppc64.c:18:
>>>>>>>>>>> [ALL ] ../string/wordcopy.c: In function
>>>>>>>>>>> '_wordcopy_fwd_aligned':
>>>>>>>>>>> [ERROR] ../string/wordcopy.c:98:26: error: 'a1' may be
>>>>>>>>>>> used
>>>>>>>>>>> uninitialized in this function [-Werror=maybe-uninitialized]
>>>>>>>>>>> [ALL ] 98 | ((op_t *) dstp)[0] = a1;
>>>>>>>>>>> [ALL ] | ~~~~~~~~~~~~~~~~~~~^~~~
>>>>>>>>>>>
>>>>>>>>>>> Looking at the code in question I think it's a spurious
>>>>>>>>>>> warning.
>>>>>>>>>>> There
>>>>>>>>>>> even appears to be an attempt to turn off the warning in
>>>>>>>>>>> sysdeps/generic/Makefile but the file is #included for
>>>>>>>>>>> powerpc so
>>>>>>>>>>> the
>>>>>>>>>>> flags applied.
>>>>>>>>>>>
>>>>>>>>>>> Bug report with full logs
>>>>>>>>>>> https://github.com/crosstool-ng/crosstool-ng/issues/1380
>>>>>>>>>>>
>>>>>>>>>> I haven't see it with gcc version 9.3.1, so it might be
>>>>>>>>>> something
>>>>>>>>>> related
>>>>>>>>>> to gcc 10 or newer. I will build a gcc 10 and check if I can
>>>>>>>>>> reproduce it.
>>>>>>>>> I just tried a crosstool-ng config selecting gcc 9.3.0 and I
>>>>>>>>> still see
>>>>>>>>> the same error.
>>>>>>>>>
>>>>>>>> I just tried to reproduce it building powerpc64-linux-gnu,
>>>>>>>> powerpc-linux-gnu
>>>>>>>> and powerpc-linux-gnu-power4 (with --with-cpu-power4) with both
>>>>>>>> gcc
>>>>>>>> 9.3.1
>>>>>>>> and 10, but without success. Are you using any special flags or
>>>>>>>> patch for gcc?
>>>>>>> There are a collection of patches
>>>>>>> https://github.com/crosstool-ng/crosstool-ng/tree/master/packages/gcc/10.2.0
>>>>>>>
>>>>>>> mostly just brought forward from older gcc versions. I'll try
>>>>>>> disabling them.
>>>>>> Even without any of the glibc or gcc patches and I still see the
>>>>>> same
>>>>>> error.
>>>>> I think I might know why you can't see the error. crosstool-ng sets
>>>>> -Werror when building glibc. So it's a warning that gets promoted
>>>>> to an
>>>>> error by -Werror.
>>>>>
>>>>> I'll update crosstool-ng to stop doing that for powerpc64 +
>>>>> glibc-2.32.
>>>> We add -Werror by default since 2.21 and have added
>>>> --disable-werror to
>>>> disable it. I am trying to understand why you are seeing this
>>>> error in
>>>> your environment because this specific code has not been touched in
>>>> a long
>>>> time and constantly built *all* supported ABI some different gcc
>>>> versions [1].
>>>>
>>>> And the last report for gcc 9 [1] and gcc 10 has not shown any
>>>> issue, neither
>>>> any testing I did with gcc 8, gcc9, or gcc10. I will try to build
>>>> some
>>>> powerpc permutations with --with-cpu and/or --disable-multi-arch.
>>>>
>>>>
>>>> [1]
>>>> https://sourceware.org/pipermail/libc-testresults/2020q3/thread.html
>>>> [2]
>>>> https://sourceware.org/pipermail/libc-testresults/2020q3/006398.html
>>>> [3]
>>>> https://sourceware.org/pipermail/libc-testresults/2020q3/006397.html
>>> Hmm the plot thickens.
>>>
>>> If it helps this is the configure line crosstool-ng ends up using
>>>
>>> BUILD_CC='x86_64-build_pc-linux-gnu-gcc'
>>> CC='powerpc64-unknown-linux-gnu-gcc -g -O2 -U_FORTIFY_SOURCE '
>>> CFLAGS=''
>>> AR='powerpc64-unknown-linux-gnu-ar'
>>> RANLIB='powerpc64-unknown-linux-gnu-ranlib' '/bin/bash'
>>> '/home/runner/work/crosstool-ng/crosstool-ng/.build/powerpc64-unknown-linux-gnu/src/glibc/configure'
>>>
>>> '--prefix=/usr' '--build=x86_64-build_pc-linux-gnu'
>>> '--host=powerpc64-unknown-linux-gnu'
>>> '--cache-file=/home/runner/work/crosstool-ng/crosstool-ng/.build/powerpc64-unknown-linux-gnu/build/build-libc-final/multilib/config.cache'
>>>
>>> '--without-cvs' '--disable-profile' '--without-gd'
>>> '--with-headers=/home/runner/work/crosstool-ng/crosstool-ng/x-tools/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sysroot/usr/include'
>>>
>>> '--disable-debug' '--disable-sanity-checks' '--enable-obsolete-rpc'
>>> '--enable-kernel=5.5.5' '--with-__thread' '--with-tls'
>>> '--enable-shared'
>>> '--enable-add-ons=no' '--with-pkgversion=crosstool-NG UNKNOWN'
>> Some notes you might consider to add on crosstool-ng:
>>
>> --without-cvs - this is a long time removed option.
>> --disable-profile - it is the default option, no need to
>> add it.
>> --disable-debug - there is no such option.
>> --disable-sanity-checks - this is only useful to disable the
>> warning that
>> using the default --prefix value
>> (/usr/local) is not
>> valid. Since it is already setting to
>> the expected
>> value this is a superfluous option.
>> --enable-obsolete-rpc - This option was removed on 2.32. The
>> NEWS contains
>> more information.
>> --with-__thread - this is another deprecated/remove
>> option, glibc now
>> requires TLS support.
>> --with-tls - Ditto.
>> --enable-shared - This is the default.
>> --enable-add-ons - Another deprecated/remove option.
> Thanks for the pointers. Some of these are hangovers from older libc
> versions. We support down to 2.12.1 so might need to be retained for
> some of these but they can be made conditional where needed.
>>> It's the same between a glibc-2.31 build and a glibc-2.32 build.
>>>
>> I check multiple build permutation with gcc-9 and gcc-10 native
>> (building
>> on a powerpc64):
>>
>> powerpc64-linux-gnu-power4
>> powerpc64-linux-gnu-power5
>> powerpc64-linux-gnu-power5+
>> powerpc64-linux-gnu-power6
>> powerpc64-linux-gnu-power6x
>> powerpc64-linux-gnu-power7
>> powerpc64-linux-gnu-power8
>> powerpc64-linux-gnu-power8-disable-multi-arch
>> powerpc64-linux-gnu
>> powerpc64-linux-gnu-disable-multi-arch
>> powerpc64-linux-gnu-power4-disable-multi-arch
>> powerpc64-linux-gnu-power5+-disable-multi-arch
>> powerpc64-linux-gnu-power5-disable-multi-arch
>> powerpc64-linux-gnu-power6-disable-multi-arch
>> powerpc64-linux-gnu-power6x-disable-multi-arch
>> powerpc64-linux-gnu-power7-disable-multi-arch
>>
>> The "-powerN" means using "--with-cpu=powerN" which
>> "-disable-multi-arch" means
>> using "-disable-multi-arch".
>>
>> I also checked on a cross build using both gcc-9 and gcc-10 on a
>> x86_64 host
>> to powerpc64-linux-gnu.
>>
>> I really think this is environment issue on your side. Maybe I can
>> fix it by
>> disabling with pragmas, but it would be hard to get any reviews without
>> actually reproducing it :/
>
> I'd tend to agree with you. Things might be working for glibc-2.31 by
> accident. I've looked over the differences between 2.31 and 2.32 and I
> agree there's nothing remotely related that could be causing this.
>
> I've seen failures in my local environment (Docker container using
> Debian buster) and in the github runners (Ubuntu 18.04). When I get a
> chance I'll try manually building glibc-2.32.
Just an update. I see the same error when building for sparc
More information about the Libc-help
mailing list