This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re: A clue for the libstdc++ problem.
On Sun, Apr 01, 2001 at 08:22:45PM -0300, Alexandre Oliva wrote:
> On Apr 1, 2001, "Zack Weinberg" <zackw@Stanford.EDU> wrote:
>
> > And how likely is it that we'll add another C++ target library which
> > shouldn't use g++ to link?
>
> The point is precisely to seamlessly add C++ target libraries that
> *do* use g++ to link. Requiring changes in their configures so that
> they find libstdc++ headers and libraries is undesirable.
>
> I agree the hack is ugly, but I find it better than dealing with each
> C++ target library individually.
>
> I would have found acceptable to special-case only libstdc++, because
> it is the one that has particular needs regarding the compiler. But
> the problem of having other C++ libraries finding libstdc++'s headers
> and library would remain.
Oh, I get it now - it's the libjava change you don't like.
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.
zw