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

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

3.7.2012 17:53, endian kirjoitti: 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/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 \

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


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

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

[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google