Re: -mmacosx-version-min and libgcc

[Geoffrey Keating <geoffk at apple dot com>]

On 30/09/2005, at 11:16 AM, Ian Lance Taylor wrote:

> 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.

I'm not gating anything on anything.  I was just pointing out that  
your statement

> It doesn't have to have precisely the same value as
> it does at top-level; it just has to work well enough for developers,
> not for users.

is not correct; it has to work for users, since it's what gets used  
in the bootstrap.  So it's not as trivial as all that.

For reference, here's what I'm testing now:

2005-09-30  Geoffrey Keating  <geoffk@apple.com>

        * Makefile.in (LIPO_FOR_TARGET): Define.
        (STRIP_FOR_TARGET): Define.

*** Makefile.in.~1.1543.~       Wed Sep 28 16:12:44 2005
--- Makefile.in Fri Sep 30 11:35:45 2005
***************
*** 344,349 ****
--- 344,350 ----
  AR_FLAGS_FOR_TARGET =
  AR_CREATE_FOR_TARGET = $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) rc
  AR_EXTRACT_FOR_TARGET = $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) x
+ LIPO_FOR_TARGET = lipo
  ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@
  RANLIB_FOR_TARGET := $(shell \
    if [ -f $(objdir)/../binutils/ranlib ] ; then \
***************
*** 358,363 ****
--- 359,374 ----
  ORIGINAL_LD_FOR_TARGET = @ORIGINAL_LD_FOR_TARGET@
  ORIGINAL_NM_FOR_TARGET = @ORIGINAL_NM_FOR_TARGET@
  NM_FOR_TARGET = ./nm
+ STRIP_FOR_TARGET := $(shell \
+   if [ -f $(objdir)/../binutils/strip ] ; then \
+     echo $(objdir)/../binutils/strip ; \
+   else \
+     if [ "$(host)" = "$(target)" ] ; then \
+       echo strip; \
+     else \
+        t='$(program_transform_name)'; echo strip | sed -e $$t ; \
+     fi; \
+   fi)

  # --------
  # UNSORTED

Attachment: smime.p7s
Description: S/MIME cryptographic signature