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
On Mon, Jan 6, 2020 at 6:02 AM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> > 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).