This is the mail archive of the gcc-patches@gcc.gnu.org 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: -mmacosx-version-min and libgcc


Geoffrey Keating <geoffk@apple.com> writes:

> > I'm not sure I understand.  AR_FOR_TARGET, for example, is in
> > BASE_FLAGS_TO_PASS in the top level Makefile.  So it will be
> > explicitly passed to the gcc Makefile, and will override any setting
> > in the gcc Makefile.
> >
> > If your concern is that there is no TARGET_FLAGS_TO_PASS in the gcc
> > Makefile, I don't see how that matters.  Either it will get the
> > setting from the top level, as passed explicitly or via MAKEFLAGS, or
> > it will be using the same setting anyhow since it is using the same
> > Makefile.
> >
> > There is a potential problem is gcc calls another Makefile recursively
> > and that other Makefile needs to use AR_FOR_TARGET, but as far as I
> > know that never happens.
> >
> > Can you give a clearer example of what won't work?
> 
> For instance
> 
> make bootstrap
> rm gcc/libgcc.a
> make quickstrap AR_FOR_TARGET=/ar/that/doesnt/exist
> 
> should fail when it tries to build libgcc.a, but it doesn't.  The top-
> level make correctly passes down the overridden AR_FOR_TARGET, but
> quickstrap does '$(MAKE) $(REMAKEFLAGS) $$LAST' and $(REMAKEFLAGS) is
> just
> 
> REMAKEFLAGS=LANGUAGES="$(LANGUAGES)" BOOT_CFLAGS="$(BOOT_CFLAGS)"
> 
> and doesn't pass down AR_FOR_TARGET.

OK, I think I see.  Clearing MAKEOVERRIDES prevents the command line
settings from being passed down.  I think this is only a problem for
the bootstrap targets, since those are the only recursive invocations
of make.  And those will probably be fixed by top level bootstrap.

In any case, what you are describing is something that doesn't work
today, and probably hasn't worked for quite some time.  I don't think
anybody has complained about it.  If you add STRIP_FOR_TARGET to the
gcc Makefile.in, then it will once again be possible for developers to
build in the gcc subdirectory, and the overall situation will be no
worse.

I don't think we should gate fixing something that people use today on
fixing something theoretically broken which nobody has complained
about.

Ian


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