Hi guys. I am trying to configure gcc. But getting the problem mentioned below.
-desktop:~$ /home/nitin/gcc-4.2.4/configure loading cache ./config.cache checking host system type... i686-pc-linux-gnulibc1 checking target system type... i686-pc-linux-gnulibc1 checking build system type... i686-pc-linux-gnulibc1 checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables.
Although this problem has been posted by many users, I am yet to find its solution. What can be the way out ? The gcc is already installed , but its for native machines only. I have to install it as cross compiler for ARM. Do I need to remove the already installed native gcc ?
But: You shouldn't do it by yourself. Except if you want to know how it works and if you have a huge amount of time. You should better use crosstool or something similar.
That the build system is a Linux with 'gnulibc1', last 'libc5' in late
1990's, sounds really odd... The guesses in configure didn't work... Furthermore the native GCC system didn't work, the builder hadn't even tried a "Hello World" with it :(
The solution is: "Please try to "compile and link a 'Hello World' program with your native GCC, that 'gcc' !" :
gcc -o hello hello.c
Here you can see that your "C compiler cannot create executables". Quite usual reason is that one has installed "only GCC". With this one can compile the Linux kernel... But when one wants to produce "apps for users", one needs to install the "development headers and libraries" aka "the C library"...
How the GCC was "tested" after its "install"? Ok, what would people say about a guy who "installs a computer" via putting one box into the table, maybe connecting it into the mains but not putting any keyboard, mouse, monitor etc. into it... Then tells that "now the computer is installed and it works!".
RTFM... The suggested "minimal command" once was :
./configure --target=$target
where $target was the required target system. For that there isn't yet any other info than the CPU type, 'ARM'.... Usual systems for ARM are those evaluation boards with a monitor like Angel or RedBoot. Then there are Linux, NetBSD, WinCE/PocketPC opsyses, RTOSes like RTEMS, uCos,... All these are different 'targets' what becomes to GCC.
Nowadays it is not "supported", recommended etc to configure GCC sources in the main source directory, neither in any of its (existing) subdirectories. Some even claim that configuring in an user-made (originally unexisting) subdirectory like in 'gcc-4.2.4/build' shouldn't work... Using a separate "build" directory is the current practice, whether it matters if this a user-created subdir in the sources or another outside the sources, may then be discussed... Generally the current minimal configure command is :
$GCC_SRC/configure --target=$target
where $GCC_SRC is the main GCC source directory, for instance :
/home/nitin/gcc-4.2.4/configure --target=$target
in this case done in a separate $BUILD directory would have done something...
the '--prefix=$prefix' and '--with-sysroot=$sysroot' are quite often required nowadays to tell the $prefix for the stuff made for the cross $host system and the $sysroot (prefix) for the stuff made for the $target system. The latter stuff is of course expected to exist already, the native target system being already there. Only very seldom people need to start from absolute scratch... For instance there already are Linux/ARM distros from Debian etc.
This sounds like one either doesn't like to use any "old hammer when producing a new hammer" (although that old one was done by oneself) or then simply doesn't know that people build their GCCs with existing '/lib', '/usr/lib' and '/usr/include' stuff (native) or with existing '$sysroot/lib', '$sysroot/usr/lib' and '$sysroot/usr/include' stuff (cross). Then producing the shared libs and all the other languages like C++ and Java would succeed immediately...
The "crosstool" AFAIK is a "tool" for the newborn "leninists and stalinists" who really believe that "making a hammer with an existing hammer is strictly forbidden!". But normal people know that :
- producing GCC from sources requires an existing C compiler, even an existing GCC (native/host one) for a cross-GCC !
- producing GCC from sources requires existing C library for the $host and the $build system - these usually are the same system. And also an existing C library for the $target system in a cross-GCC build case
That the builder doesn't know what "creating executables" means, cannot compile and link a Hello World application in order to "test the installed GCC, whether it can create any executables", isn't a very good starting point at all :(
So if it would be useful for a "future car-builder" to toy with some tools and existing car(s) first in order to learn what tools and cars are... then it would be useful here first to toy with the native GCC and with some existing cross GCCs for ARM (for 'arm-elf', 'arm-linux', 'arm-linux-gnueabi' etc.). "LWTFG" ("Look With The F***ing Google") method will tell where one can find these but almost everyone could list some places like :
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.