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