From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22288 invoked by alias); 29 Jan 2008 13:14:56 -0000 Received: (qmail 22278 invoked by uid 22791); 29 Jan 2008 13:14:55 -0000 X-Spam-Check-By: sourceware.org Received: from pne-smtpout3-sn2.hy.skanova.net (HELO pne-smtpout3-sn2.hy.skanova.net) (81.228.8.111) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 13:14:31 +0000 Received: from [192.168.0.2] (88.193.134.7) by pne-smtpout3-sn2.hy.skanova.net (7.3.129) id 478BDB96000CBACB for gcc-help@gcc.gnu.org; Tue, 29 Jan 2008 14:13:30 +0100 Message-ID: <479F26FF.5070603@wippies.com> Date: Tue, 29 Jan 2008 20:24:00 -0000 From: Kai Ruottu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: Building a cross-compiler References: <479E4EEA.9050101@ieee.org> <479E68C9.1020705@ieee.org> <7EC02895-AD23-4469-A5C6-507C086D3B45@mit.edu> In-Reply-To: <7EC02895-AD23-4469-A5C6-507C086D3B45@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00318.txt.bz2 Michael Witten wrote: > Creating a cross compiler _should_ be the easiest > thing in the world, but the gcc is so backasswards > that it can be troublesome. Most problems really come from the total ignorance about what GCC is and what it isn't :( A "C compiler" usually includes a "C library" and all the required "binutils" like 'as' (assembler) and 'ld' (linker). GCC then is a "bare compiler" which only produces assembly (symbolic machine code) text... So a GCC builder MUST provide both the binutils and the C library BEFORE starting to build a GCC ! People building native GCCs don't need to care about these things, of course there are those prebuilt binutils for instance in '/usr/bin' and a prebuilt C library in '/lib', '/usr/lib' and '/usr/include', in the Linux case. So those required "target binutils and target C library" are already there.... We should always remember that the "native GCC" is the DEFAULT GCC type and the cross GCC is only "another incarnation of the native GCC" on some other host! And therefore all the same prerequisites will exist... So many cross GCC builders have really weird opinions about what the GCC build should require and what it shouldn't, totally forgetting that "native" default :( Producing a cross GCC then is just as easy as producing a native one when one hasn't any weird "attitude problems". One accepts those prerequisites for the binutils and the C library and the build is easy as a pie... This of course is true only with "existing" targets. In the Linux target cases all the Linux distros are "existing". Some with that attitude problem always claim that they don't exist or that people shouldn't care or should be prepared to the doom day when all those prebuilt Linux binaries have been destroyed :) When one wants to make one's own Linux distro "from scratch", there are many choices to do that crosstoolchain with which to produce the self-built Linux distro. The easiest way is to bootstrap with something "existing". Making the target binutils is easy and doesn't require anything else than the host GCC (with its own binutils and C library). But producing GCC is problematic, a "Catch 22" or "Chicken and egg", because the target C library is missing :( The produced GCC will produce it but when producing GCC requires the target C library during its build, what on earth to do? Fortunately the world is full of similar cases... A car builder may accept using "wrong but suitable tyres" when driving to the tyre shop for those "right" tyres. Driving with bare wheels isn't a sane alternative... In cross GCC world this means for instance that a glibc for Linux/MIPS is "suitable" when producing a GCC for a "self-made" Linux/MIPS distro... Or a Linux/MIPSEL one. One place where to find it is a Debian Linux archive, both 'mips' and 'mipsel' targets are supported... When one uses some existing C library during the "first" GCC build, one learns the "normal GCC build", used with existing targets and when updating the GCC. Much harder is to try to start from absolute scratch... The sadly famous "crosstool" tries to help the people with the attitude problems. When using it people will never learn how others will build their own crosstoolchains in less time than one hour :( Even with old < 1 GHz PCs.... When always starting from absolute scratch again, the productivity is horribly low! >>> Last time I did it, I found I had to have the binutils --prefix >>> directory >>> the same --prefix as the compiler. This is the assumption! A cross GCC must use its own 'as' and 'ld', with their bare names, from somewhere else than the native GCC! It is not a "human user" for whom those '$target-'s are aimed :( Both the native and a cross GCC will try to launch 'as' and 'ld' from their own built-in search directories seen with the well-known (even for newbies) : $target-gcc -print-search-dirs Every newbie of course can ask on-line help : $target-gcc --help from the GCC if not remembering those most usual options... Or can RTFM.... Ok, the '$tooldir/bin' aka '$prefix/$target/bin' is the place where those target binutils will be installed. There are many $gcc-version specific search places for GCC version specific 'as' and 'ld' if these are required to work-around something. People can have installed many GCC versions for one $target, these generally using the same binutils and the same C library. Having many native GCCs isn't rare, neither having many cross GCCs for one target. All the previous was for those "true" cross GCCs, for the "system targets" which also have native GCCs for them... The method for a GCC build for an "embedded target", one which doesn't have any "native GCC" ever, then is totally different case ! Using the 'newlib' free C library is the assumption for all those "unreal" targets like the "elves". Some claim that they have seen an 'elf' or an 'angel' (the default target for 'arm-elf'), or that 'p(oke)mon' for the 'mips-elf', used to be patched as the default target in the GCC's 'specs' file. But I haven't seen either :( I have seen Linuces, Unices and such "real" targets however... The question is where on earth those executables will run? If one doesn't ask this question, then those "basic courses about computers" have failed miserably... Producing a GCC for a newlib-using target basically requires only : 1. the target binutils 2..the generic newlib headers 3. using the '--with-newlib' in the GCC configure The prerequisites 1. and 2. means these being preinstalled, the 2. a single 'cp -r' command made for the proper 'newlib/libc/include' in the sources.... After that everything belonging to the C/C++ compilers should be produced! There are very old and weird bugs hurting this but then these things have been discussed tens or hundreds or thousands times... Like that "sys-include bug". Just use Google and all these discussions will be found!