Am Mon, 2002-03-11 um 19.10 schrieb Phil Edwards:
> On Mon, Mar 11, 2002 at 03:28:29AM +0100, Ralf Corsepius wrote:
> > Am Mon, 2002-03-11 um 00.12 schrieb Phil Edwards:
> > > AC_PROG_CC tries to do something in
> > > the "checking for C compiler default output" section which fails (cannot
> > > create executables) when cross-compiling. If I edit the configure script
> > > to ignore the error, I get two steps further:
> > >
> > > checking for C compiler default output...
> > > checking whether the C compiler works... yes
> > > checking whether we are cross compiling... yes
> > > checking for executable suffix... configure: error: cannot compute EXEEXT:
>cannot compile and link
> [...]
> > If building inside of the gcc-source-tree, there are various things
> > which can go wrong. E.g. this check might be run at a time when the
> > c-toolchain is incomplete and not yet usable.
>
> This looks like the problem, or at least one of the problems. See below.
>
>
> > It could also be the side-effect of something else, e.g. the toplevel
> > configure script setting the canonicalization names to something which
> > is incompatible to autoconf-2.52 (--host etc.), rsp. the toolchain might
> > also be broken itself (several gnu-cross-toolchains are in pretty bad
> > shape.)
>
> Ugh.
<sigh>
Unfortunately yes.cf. Joel Sherrill's reports on [EMAIL PROTECTED]
</sigh>
> > Could you please check the part of the config.log corresponding to the
> > failing AC_PROG_CC for the actual reason of the breakdown you are
> > observing?
>
> configure:1864: checking for C compiler default output
> configure:1867: /home/pme/build/B/gcc/xgcc -B/home/pme/build/B/gcc/
-nostdinc -B/home/pme/build/B/powerpc-eabisim/newlib/ -isystem
/home/pme/build/B/powerpc-eabisim/newlib/targ-include -isystem
/home/pme/src/unified/newlib/libc/include
-B/home/pme/build/install-2002-03-11-ppc/powerpc-eabisim/bin/
-B/home/pme/build/install-2002-03-11-ppc/powerpc-eabisim/lib/ -isystem
/home/pme/build/install-2002-03-11-ppc/powerpc-eabisim/include
-L/home/pme/build/B/ld -g -O2 conftest.c >&5
> /home/pme/build/B/gcc/collect-ld: cannot open sim-crt0.o: No such file
or directory
> collect2: ld returned 1 exit status
> configure:1870: $? = 1
> configure: failed program was:
> #line 1848 "configure"
> #include "confdefs.h"
>
> int
> main ()
> {
>
> ;
> return 0;
> }
> configure:1893: error: C compiler cannot create executables
>
>
> The sim-crt0.o file is in powerpc-eabisim/libgloss/rs6000/ but that directory
> isn't being searched. I'm scared to even ask what needs to be changed to
> make that work.
:)
AFAIS, the check fails, because CC can't link because it is not finding
something (Without knowing the details of the gcc-port you are using, I
presume sim-crt0.o to be the compiler's startup code).
Therefore, this particular problem probably is related to a problem with
integration of libgloss into building of gcc.
A potential hack/work-around/fix would be to let gcc's toplevel
configury pass appropriate LDFLAGS/CFLAGS down to libstdc++'s configure
(-L...libgloss, -B ... or similar) or to let libstdc++'s configure treat
"in-sourcetree building w/ newlib/libgloss" as a special case.
However, ... I doubt this will help in general, because some gcc-target
have portions of their libc outside of the source-tree and apply newlib
as minimal, incomplete libc to bootstrap the OS.
Continuing this thought scares me :)
In its final consequence it would mean either gcc's configuration to be
basically broken or autoconf not to be applicable inside of gcc's
source-tree, because autoconf pre-requires a functional c-compiler.
Ralf
