This is the mail archive of the
mailing list for the GCC project.
Re: multiple definition of symbols" when linking executables on ARM32 and AArch64
- From: Matthias Klose <doko at ubuntu dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Andrew Pinski <pinskia at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 6 Jan 2020 14:29:24 +0100
- Subject: Re: multiple definition of symbols" when linking executables on ARM32 and AArch64
- References: <AM5PR0801MB203510D69D436B84B59640DA833C0@AM5PR0801MB2035.eurprd08.prod.outlook.com>
On 06.01.20 13:30, Wilco Dijkstra wrote:
> On 06.01.20 11:03, Andrew Pinski wrote:
>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose <firstname.lastname@example.org> 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
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?