Re: GCC 4.7.1 error: Link tests are not allowed after GCC_NO_EXECUTABLES.

[Kai Ruottu <kai dot ruottu at wippies dot com>]

3.7.2012 17:53, endian kirjoitti:
> http://old.nabble.com/file/p34108047/config.log config.log
>
> Host GCC Version: 4.4.6
> Build GCC Version: 4.7.1
>
> Error Summary:
>
> checking whether the /home/matt/mycc/src/gcc-4.7.1-build/./gcc/xgcc
> -B/home/matt/mycc/src/gcc-4.7.1-build/./gcc/
> -B/home/matt/mycc/arm-linux-gnueabi/bin/
> -B/home/matt/mycc/arm-linux-gnueabi/lib/ -isystem
> /home/matt/mycc/arm-linux-gnueabi/include -isystem
> /home/matt/mycc/arm-linux-gnueabi/sys-include    linker
> (/home/matt/mycc/src/gcc-4.7.1-build/./gcc/collect-ld) supports shared
> libraries... yes
> checking dynamic linker characteristics... configure: error: Link tests are
> not allowed after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/home/matt/mycc/src/gcc-4.7.1-build'
> make: *** [all] Error 2

This means that the just produced GCC cannot create executables with the
am-linux-gnueabi targeted binutils and the arm-linux-gnueabi targeted
standard C library, 'glibc' in this case, which you probably haven't 
installed.

Making a cross GCC doesn't differ in any way from making a native GCC what
comes to the target binutils and target C library.  A native system 
includes the
target C library in '/lib', '/usr/include' and '/usr/lib' quite 
automatically, at
least the parts required to produce executables for the native 
build/host/target
system.  For a cross GCC the default is that one provides the target C 
library,
so the question is "does it exist?".  What do you think, is it so that 
there are no
glibcs for arm-linux-gnueabi?

The fact is that almost ANY prebuilt glibc made for arm-linux-gnueabi 
would be
suitable for the task - to serve as the required "target C library" 
during the GCC
build!  And that it is totally dependent on the GCC builder which 
prebuilt tools
and other prerequisites one accepts...  For instance in a native GCC 
build accepts
a prebuilt glibc which is NOT built with the new native GCC but with 
something
else, the original system GCC.  After the new GCC is ready and works it 
is up to
the builder to decide whether one REALLY wants to replace the original 
glibc in
the system with a self-made one - that could be dangerous!  In a cross 
GCC case
there would be no danger if the new crosstoolchain will be used to 
create the
whole target system from scratch, including the runtime parts in glibc...

> Configure Options (sh excerpt):
>
> ${SRC_DIR}/${GCC}/configure \
>          --enable-obsolete \
>          --target=arm-linux-gnueabi \
>          --disable-threads \
>          --enable-language=c \
>          --prefix=${PREFIX} \
>          --without-headers \
>          --disable-multilib \
>          --disable-decimal-float \
>          --disable-libgomp \
>          --disable-libmudflap \
>          --disable-nls \
>          --disable-shared \
>          --disable-libssp \
>          --with-newlib \
>          --with-system-zlib

If you would have a prebuilt glibc for arm-linux-gnueabi (from Debian, 
Codesourcery
etc) you would simply copy/unpack it into a suitable $sysroot and point 
to it via
'--with-sysroot=$sysroot' in binutils and GCC configures. And not use 
those weird
'--without-headers' and '--with-newlib'  options (for your target), and 
not disable
so many things...

> Notes:
>
> I can run a 'make all-gcc', and there are gcc executables that get installed
> in my target directory, but am not sure if the compilation is actually
> broken.

I really don't know whether your "brain damaged" GCC really could 
compile the glibc
sources :-(   A "working" GCC made with some existing temporary glibc of 
course should
be capable to do this!

A "working GCC" here means a toolchain which can create executables for 
the target
system, 'arm-linux-gnueabi'.  At least as simple as "Hello World" in C...
>    Any ideas about the source of the error?  I am currently learning
> how to build tool chains, so please excuse any gross errors I might have
> made with configure.

The "Link tests are not allowed after GCC_NO_EXECUTABLES" could be told 
otherwise:
"When the toolchain cannot create executables for the target, it is 
impossible to make
any link tests in order to see what features the target C library has 
and what not!". So
you should refresh your memory about once learned things like 
"compiling" and "linking"...