DJ Delorie wrote: >> The key problem is that we have two ways > > And then he lists *three* ;-)
:-) >> To accomplish that, we need to avoid autoconf tests for features that >> require running target programs; > > The problem I'm running into is that I can't even *link* a target > program at that point. The C library (including crt0 and linker > scripts) have not yet been installed. 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). >> Hence, my opinion is that we ought never to use autoconf tests to >> figure these things out, even for native compilation, relying >> instead on hard-coded target information of --enable-* flags. > > Such as --enable-libfoo-a ? In this case, for example, --enable-libstdc++-symvers, or some such. >> To that end -- and I know this is going to be unpopular -- I think we >> should require that you have a C library available at libstdc++ build >> time, either by having one already installed, or by passing appropriate >> -I/-L options to libstdc++. > > We normally pass the newlib -I/-L, but in my case, I also need to > point into libgloss for a few things. That gets nasty as there's no > consistency there. 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. The thing I'd discourage you from doing is running autoconf only in some configurations (e.g., only if native, or only if $build = $host). In particular, adding a configure option which is unconditionally honored, if present, but falling back to autoconf if it's not present, doesn't bother me; that still doesn't introduce any differences based on whether we're in a cross, native, or Canadian configuration. It might be that it's more expedient to add such a configure option than to fix things so that you can link, but, really, first and foremost, I'd encourage you to fix things so that you can link. (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.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
