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
