[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Severe performance problem and proposed solution

From: Zack Weinberg
Subject: Re: Severe performance problem and proposed solution
Date: Mon, 25 Feb 2002 11:27:46 -0800
User-agent: Mutt/1.3.27i

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> <>;
> 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 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

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/ to see some of the things it does
right now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]