[PATCH] GCC compatibility: pass -z linker options to the linker

Joerg Sonnenberger joerg at britannica.bec.de
Wed Jul 16 00:06:47 PDT 2014


On Tue, Jul 15, 2014 at 05:20:00PM -0700, Eric Christopher wrote:
> On Tue, Jul 15, 2014 at 4:57 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Tue, Jul 15, 2014 at 03:11:23PM -0700, Eric Christopher wrote:
> >> I'm sorry Joerg, you've got sufficient people disagreeing with you
> >> here and this is a fairly well established option in gcc that we're
> >> just getting compatibility with here. A warning would be both annoying
> >> for users and pointless. I'm going to go ahead and have the patch
> >> submitted.
> >
> > How is -z well established when it wasn't even documented? GCC passing
> > unknown flags to the linker is a misfeature. Warning about it is the
> > very least we should do. While it might be too late for -u, no new
> > option should be added to this list. That said, I would like to see a
> > sane use case for -u, independent of whether it should be warned about
> > or not. I tried to use it in the past and it didn't do the things I
> > expected from it.
> >
> 
> -z has been silently passed along to the linker as long as I can tell
> (r262) in gcc. At least as long the gcc.c file has existed. That it
> wasn't documented well, you can blame at least this patch:

GCC has disallowed a lot of its misfeatures since that point. We don't
implement all those misfeatures either. What happens if/when IBM
provides a patch for AIX support in driver? Now we have to recognize -z
and add -b svr4 as well to make it work. Take a look back at the
recently added -R option. That has been used as implicit linker flag
*much* more often than -z. We did the wrong thing for a very long time
and hardly anyone noticed. The complains have come now, because we
finally do the right thing and bail out on junk. While that might be a
bit hard, a warning is certainly justified. The clang driver is not the
linker, it should not try to be. Linker flags are not the same over
platforms, so accepting additionals comes with an unnecessary burden for
future targets.

Joerg



More information about the cfe-commits mailing list