Re: libstdc++ in a combined tree

[DJ Delorie <dj at redhat dot com>]

> Right, I understand.  Assuming that they exist at this point, you
> could theoretically pass enough options to make it work -- although,
> as you say, it's hard to know what those options ought to be.  If
> everything is set up right, it's -I options (for libc headers), -L
> options (for libc and libgloss), and a -T option (for appropriate
> linker script).

I did that for m32c, the problem is that we're explicitly denying
linking with a GCC_NO_EXECUTABLES, then we link anyway.  It will
*always* break, regardless of -I/-L options, because autoconf itself
is complaining.

> Personally, I'd just not do a one-tree build. :-) But, I know that's
> popular with lots of folks, for various reasons, including not
> having to build the compiler twice.

Right, our internal trees are *all* one-tree builds.  It's vastly
simpler to just do "./configure; make; make install" than all the
nastiness needed to bootstrap a cross compiler.  It still won't fix
the libstdc++ bug, nor does it catch the libgloss bits.

> (One big-hammer solution there is to revive the "staged install"
> proposal, where you would do something like "make install
> DESTDIR=$objdir/install" after building each component, so that
> Newlib, libgloss, etc., would already be in this staging area,
> before building libstdc++.  I think that would simplify a lot of our
> Makefiles -- but, of course, necessitate a fair bit of change.)

DJGPP builds this way.  The actual Makefile targets *are* in the local
install tree, so they get built-in-place.  Then you just cp -rp the
bits you need (or in djgpp's case, zip them together for distribution).