Re: Severe performance problem and proposed solution

[Ralf Corsepius]

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 <address@hidden> 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