multiple definition of symbols" when linking executables on ARM32 and AArch64

Martin Liška mliska@suse.cz
Mon Jan 6 13:37:00 GMT 2020


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 <doko@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
> 



More information about the Gcc mailing list