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

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Jan 6, 2020 at 5:29 AM Matthias Klose <doko@ubuntu.com> 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
> 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?

It is hard to get a warning for things like this.
Also the documentation for -fcommon was changed and made clear for
8.1.0[1] that the default might be changing because it is not required
by ISO C.
"This is the behavior specified by -fcommon, and is the default for
GCC on most targets. On the other hand, this behavior is not required
by ISO C, ..."
-fno-common: "This inhibits the merging of tentative definitions by
the linker so you get a multiple-definition error if the same variable
is defined in more than one compilation unit. "
So I think it was "deprecated" in GCC for the last 2 major releases.
Though nobody reads the manual these days.

Thanks,
Andrew Pinski

[1] https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Code-Gen-Options.html#index-fno-common

>
> Matthias