Re: Severe performance problem and proposed solution

[Ralf Corsepius]

Am Die, 2002-02-26 um 08.44 schrieb Zack Weinberg:
> On Tue, Feb 26, 2002 at 07:13:17AM +0100, Ralf Corsepius wrote:
> > 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.
> 
> Yeah.  Hacks to deal with all three are tangled together in the gcc
> configure scripts (large sense of gcc, including all the runtime libs
> shipped with it) so we solve all of them, or none.
> 
> Note however that it's not a case of building _arbitrary_ c-libraries
> while building GCC.  All the libraries that get built with a
> just-created cross compiler are language runtimes of some sort, and
> their configure scripts do have some degree of support for this
> situation.  The default set is
> 
> newlib libf2c libffi libiberty libjava libobjc libstdc++
> 
> (newlib being a minimal C runtime.)
I know, ... I am one of the guys behind RTEMS :)

IMO, these fall into 2 categories:

a) c-libs required by gcc and it's c-frontend: newlib (and probably
libiberty)
b) support libs required by gcc but not by gcc/c (Built ontop of a
minimal gcc/c): libf2c, libffi (?), libjava, libobjc, libstdc++.

The basic difference I see between these categories is b) probably being
configurable/buildable after building gcc's c-frontend, which would mean
they probably could rely on gcc's c-frontend and exploit autoconf's
checks.

> ...
> > 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.)
> 
> I am not sure what happens exactly.  Unfortunately this means I can't
> respond to a lot of your points.  Comments in libstdc++-v3/configure.in
> imply that you're right in principle but the current situation doesn't
> allow it:
> 
> if test -n "$with_cross_host" || test x"$build" != x"$host"; then
>   # This lets us hard-code the functionality we know
>   # we'll have in the cross target environment. "Let" is a
>   # sugar-coated word placed on an especially dull and tedious hack, actually.
>   # Here's why GLIBCPP_CHECK_MATH_SUPPORT,
If libm is accessable at the time entering such a check, this should
work with autoconf-2.5x. libstdc++ would not be any different from
normal application libraries (external from gcc), except that building
as part of the gcc-tree would require special setting for CC and related
flags ("Building ontop of a gcc toolchain").

>    and other autoconf macros
>   # that involve linking can't be used:
>   # "cannot open sim-crt0.o"
>   # "cannot open crt0.o"
This is a different issue. 

Some gcc-configuration have their actual startup-files outside of gcc's
source-tree (esp. embedded systems' OSes, e.g. RTEMS) rsp. these
startup-files might not yet be available at the time when configuring
gcc. 

However, AFAIK, gcc configurations normally provide a default startup
file, which could/should suffice as a stub here. There might be
exceptions, I am not aware about (sim-crt0.o could indicate dependencies
on gdb's or external simulators' startup code).

>   # etc. All this is because there currently exists no unified,
>   # consistent way for top level CC information to be passed down
>   # to target directories: newlib includes, newlib linking info,
>   # libgloss versus newlib crt0.o, etc. When all of this is done, all
>   # of this hokey, excessive AC_DEFINE junk for crosses can be removed.
> 
> > 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.
> 
> Really?
Yes, but the keyword is "supposed". 

So, at least, say 90% of the problems have been solved. There remain
some issues and unclear spots (primarily documentation weaknesses wrt.
canonicalization, cf. below), but it basically works. 

>  I'll have to poke at this again with 2.52.  It certainly did
> not work in 2.50.
Hmm, I think the issue here is the conventions on --build, --host and
--target having changed and these changes not having been reflected to
gcc's toplevel configure-script (the "Cygnus configure-script"). 

There are other issues lurking, wrt. autoconf playing tricks with
environment variable (esp. *_alias), which can interfere with gcc's rsp.
libstdc++'s expectations (cf. the autoconf mailing-list archive, there
have several threads within the last couple of months where these issues
had been discussed - unfortunately no conclusion had come out of this).

At least for RTEMS, autoconf's environment variable handling had caused
me to implement some work-arounds, but I don't see how these could
affect gcc's configuration unless toplevel configure script was
autoconfizcated.

[For RTEMS, I am using an autoconf/automake-based toplevel
configure-script which has a similar functionality as gcc's toplevel
configure-script. There, autoconf's behavior interferes.]

> > Actually, I am inclinded to think, throwing out all of the GLIBCPP
> > things will probably work, but .. you probably know better than me :)
> 
> I don't know, actually.  I don't normally work on the runtime
> libraries.  I just seem to be the person who's willing to dig deeper
> into the configure scripts than anyone else.
:)

I would be volunteering for a try, but my personal time-constraints
currently are permissively tight to do so :(.

Ralf