Re: Severe performance problem and proposed solution

[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.)

...
> 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, and other autoconf macros
  # that involve linking can't be used:
  # "cannot open sim-crt0.o"
  # "cannot open crt0.o"
  # 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?  I'll have to poke at this again with 2.52.  It certainly did
not work in 2.50.

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

zw