On 1/6/20 2:29 PM, Matthias Klose wrote:
On 06.01.20 13:30, Wilco Dijkstra wrote:
On 06.01.20 11:03, Andrew Pinski wrote:
+GCC
On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose <d...@ubuntu.com> wrote:
In an archive test rebuild with binutils and GCC trunk, I see a lot of build
failures on both aarch64-linux-gnu and arm-linux-gnueabihf failing with
"multiple definition of symbols" when linking executables, e.g.
THIS IS NOT A BINUTILS OR GCC BUG.
GCC changed the default to -fno-common.
It seems like for some reason, your non-aarch64/arm builds had changed
the default back to being with -fcommon turned on.
what would that be? I'm not aware of any active change doing that. Packages
build on x86, ppc64el and s390x at least.
Well if you want to build old archived code using latest GCC then you may need
to
force -fcommon just like you need to add many warning disables. Maybe you were
using an older GCC for the other targets? As Andrew notes, this isn't
Arm-specific.
found out about why. Started the test rebuild with trunk 20191219, then gave
back all build failures yesterday with trunk 20200104. And I saw most of the
armhf/arm64 ftbfs when I retriggered failing builds. To get consistent results
I should finish that test rebuild with the -fno-common change reverted.
However, this is an undocumented change in the current NEWS, and seeing
Hello.
It's waiting for a review:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00311.html
literally hundreds of package failures, I doubt that's the right thing to do, at
least without any deprecation warning first. Could that be handled, deprecating
in GCC 10 first, and the changing that for GCC 11?
I can confirm that it will cause a significant fallout. We're expecting with
Jeff something like:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00333.html
Our strategy (as openSUSE) would be to use GCC default (-fno-common) and let
package maintainers to report issues and possible add -fcommon to $optflags
on package basis.
Martin
Matthias
