Am Mon, 2002-02-25 um 20.27 schrieb Zack Weinberg: > On Mon, Feb 25, 2002 at 07:32:30PM +0100, Akim Demaille wrote: > > >>>>> "Zack" == Zack Weinberg <[EMAIL PROTECTED]> writes: > > > > Zack> It may well be good enough. I cannot test it because (a) I have > > Zack> no access to any of the affected machines, and (b) for other > > Zack> reasons, libstdc++ cannot currently migrate away from autoconf > > Zack> 2.13. (See the discussion at > > Zack> <http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01986.html>; > > Zack> suggestions would be appreciated.) > > > > I just had a look, and could find exactly what advice you'd like. > > Also, we are working on 2.53. If you need special features, please > > let us help you by specifying them! > > I assume you meant "couldn't"? > > The show-stopper problem we had was something like this: > > The configure script for a target library (i.e. a library which might > be being built with a just-created cross compiler) does AC_PROG_CC, > but that is likely to fail with a just-created cross compiler, because > we're in the process of building the runtime libraries that AC_PROG_CC > will try to link against. The configure scripts and Makefiles are > aware of this and do not try to do things that will not work. They > have a kluge in place to prevent AC_PROG_CC from failing spuriously. > > The kluge does not work anymore with Autoconf 2.5x. That's fine. It > provides what was intended to be a better replacement, the > AC_NO_EXECUTABLES macro. Unfortunately, *any* use of AC_TRY_LINK or > AC_TRY_RUN is forbidden - at generation time - in a configure.ac that > uses AC_NO_EXECUTABLES, and that's too extreme. Some of the runtime > libraries need to do AC_TRY_LINK tests to probe libraries that they > depends on. (For instance, the C++ runtime library needs to find out > some characteristics of the C runtime library.) The configure script > takes precautions when it is executed to prevent spurious link > failures (in the simplest case, hardwiring results to use when being > cross compiled) but AC_NO_EXECUTABLES won't let us use AC_TRY_LINK at > all. > > I'm not sure what the _right_ thing to put into autoconf 2.53 would be > to solve this problem. I don't use cross compilers myself. You can > look at libstdc++-v3/configure.in to see some of the things it does > right now. I think, you are actually describing at least 3 different problems at the same time.
1. Building arbitrary c-libraries while building gcc. 2. Building libstdc++ 3. Cross-compilation. The difference I seen between 1 and 2, is that while you have little chance to check the target system's characteristics wrt. 1 (ie. to apply standard autoconf-means), you have a chance to check the target system's characteristics for libstdc++ if c-gcc+support-libs is available when configuring libstdc++. Ie. if libstdc++'s configuration takes places sequentially, subsequent to building the c-frontend+support-libs to gcc, standard autoconf-checks would probably be applicable (eventually having to preset CC and CFLAGS etc.) The AC_TRY_RUN/AC_PROG_CC issue is supposed to be solved with autoconf-2.5x, because AC_PROG_CC doesn't try to run an executable anymore. I.e. basically, cross-compilation is supposed not to be any different from native compilation. AC_TRY_COMPILE/AC_TRY_LINK should also not be an issue if carefully being applied, ie. if testing for "c"-features only and if presetting CC (CC=$(top_builddir)/gcc/xgcc)), CFLAGS (-B, -specs, etc.), CPPFLAGS (include/library-paths, etc) etc. to point to the required files inside of neighboring directories of the gcc-tree. So, IMHO, the keys to your issues would probably be to serialize and preset things if building libstdc++ as part of the gcc-tree. However, I am not familiar enough with libstdc++'s and gcc's configuration to be sure about it (In particular, I am not sure when libstdc++ is configured, simulaneously or after gcc?). Actually, I am inclinded to think, throwing out all of the GLIBCPP things will probably work, but .. you probably know better than me :) Ralf
