autoconf
[Top][All Lists]
Advanced

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

Re: Severe performance problem and proposed solution


From: Ralf Corsepius
Subject: Re: Severe performance problem and proposed solution
Date: 14 Mar 2002 06:01:01 +0100

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 address@hidden 
</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 





reply via email to

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