[PATCH] Re: A clue for the libstdc++ problem.

[Alexandre Oliva]

On Apr  1, 2001, "Zack Weinberg" <zackw@Stanford.EDU> wrote:

> How's this sound: at the beginning of the target configure sequence,
> create libstdc++.FLAGS in the top level of the target build directory
> ($objdir/$target).  It just has '-nostdinc++' in it to start.
> libstdc++/src/Makefile overwrites that file with the correct switch
> set.  We augment $(CXX_FOR_TARGET) with `cat libstdc++.FLAGS`
> *directly* in the rule which invokes target library configure.
> CXX_FOR_TARGET then has no backquotes in it, and is not damaged by
> being evaluated in the FLAGS_TO_PASS sequence.

I'm not sure it's better than the patch that I proposed (which worked
for me, BTW).  I'd rather have configure flags centralized in
configure files, not hidden in Makefile templates.

Besides, there's at least one good thing about the patch I proposed:
it introduces a general mechanism that other target libraries may use
to specialize flags they get.  I can foresee having specialized
CC_FOR_TARGET for newlib (and maybe glibc?), and perhaps a specialized
GCJ_FOR_TARGET for libjava, so that other Java libraries find Java
standard libraries in the build tree.

I'm tempted to install the patch I have now, just to get things back
into a working shape, and then proceed with the discussion about the
best way to address it, if anybody still has the energy for it.  If
nobody screams in horror ;-) about the patch that introduces
CXX_FOR_TARGET_FOR_RECURSIVE_MAKE, I'll check it in in half an hour or
so.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me