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

[Alexandre Oliva]

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

> Your patch doesn't change the fact that presently only
> libstdc++/src/Makefile knows the proper switches to use when building
> libraries against the just-built libstdc++.

Which is a good thing, IMO.  We concentrate the information about how
to find libstdc++ headers and libraries in libstdc++, and export it in
a form any other tool can use; in particular, the top-level Makefile
can use it.  My plan is to do something similar for newlib, and,
perhaps, libgloss, so that we can get rid of the many places in which
these flags are hardcoded again and again.

> I don't think it will work with my shell.  It looks like it uses the
> same construct as your previous patch that didn't work.  I could be
> wrong.

You probably are.  I believe I could never reproduce your problem
because I'd always run `make all' after bootstrapping the compiler,
assuming they were equivalent.  Whenever I ended up with one of the
weird problems of libtool not being able to infer the tag name, I
attributed it to cache polution, cleaned the cache and run, guess
what: `make all', not `make bootstrap'.  So, my suspicion that it was
just the cache that got dirty somehow was ``confirmed.''

The construct that didn't work for you, and probably for nobody at
all, had the problem that it was expanded in the top-level Makefile
when re-entering itself after bootstrap, as you found out.

Or maybe you're referring to my Friday's patch, that said:

        "CXX_FOR_TARGET='$(CXX_FOR_TARGET)'"

The double quotes around the whole thing messed it up, because
single-quotes aren't taken out.  I had meant to not have the double
quotes.  Unfortunately, taking them out was not enough, for the
reasons explained in the comment in configure.in, in the following
revised (comments-only) patch, that I'm checking in for now.