This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <> 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.
>> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]