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

Andrew Pinski pinskia@gmail.com
Mon Jan 6 14:08:00 GMT 2020


On Mon, Jan 6, 2020 at 6:02 AM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
>
> Hi,
>
> > 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?
>
> This change was first proposed for GCC8, and rejected because of failures in the
> distros. Two years have passed, and there are still failures... Would this change if
> we postpone it even longer? My feeling is that nobody is going to actively fix their
> code if the default isn't changed first.
>
> > It is hard to get a warning for things like this.
>
> Could the linker warn whenever it merges common symbols or would that give
> many false positives?

That might get some false positives for some Fortran code (where
common symbols are "common") (and maybe C++ code; C++ sometimes uses
common symbols but only if weak support does not exist).

Thanks,
Andrew Pinski


>
> Wilco



More information about the Gcc mailing list