From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28486 invoked by alias); 29 Jan 2008 00:37:32 -0000 Received: (qmail 28474 invoked by uid 22791); 29 Jan 2008 00:37:31 -0000 X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 00:36:59 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m0T0atV5012723; Mon, 28 Jan 2008 19:36:56 -0500 (EST) Received: from MACGREGOR-TWO-TWELVE.MIT.EDU (MACGREGOR-TWO-TWELVE.MIT.EDU [18.239.5.212]) (authenticated bits=0) (User authenticated as mfwitten@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m0T0apnv020520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jan 2008 19:36:55 -0500 (EST) Cc: gcc-help@gcc.gnu.org Message-Id: <7EC02895-AD23-4469-A5C6-507C086D3B45@mit.edu> From: Michael Witten To: "Wenton L. Davis" , John Carter In-Reply-To: <479E68C9.1020705@ieee.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Building a cross-compiler Date: Tue, 29 Jan 2008 05:05:00 -0000 References: <479E4EEA.9050101@ieee.org> <479E68C9.1020705@ieee.org> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.00 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/msg00303.txt.bz2 On 28 Jan 2008, at 6:44 PM, Wenton L. Davis wrote: > John Carter wrote: >> >> It's a _very_ dark art.... > No kidding!!!! I disagree wholeheartedly. Creating a cross compiler _should_ be the easiest thing in the world, but the gcc is so backasswards that it can be troublesome. >> Some hints:... >> >> There is a nasty tangly dependency between binutils, libc and the >> compiler. >> >> Last time I did it, I found I had to have the binutils --prefix >> directory >> the same --prefix as the compiler. This is definitely the case; gcc is really just an interface to a bunch of different tools, so it needs to know where to find those tools. It would be nice if there were a configure directive to specify the location of binutils tools for greater flexibility. For now, just make --prefix the same for both. In any case, you're supposed to be able to put the binutils source subdirectories (gprof, opcodes, bintutils, ...) inside the top level of the gcc source code so that one configure invocation handles both; both source trees are actually 2 separate views of a larger tree. > At this point, I tried the brute force, copying the exact command > line, but adding to it the -I../../(etc) to find the unistd.h and > pthreads.h, but it failed because of an #endif without #if error... > I thought I'd manually modify this file, but it was automagically > created by fixincludes. (?!?!?) Do you need libc on these other targets? If not, use --without-headers to indicate that you have no intention of building libc or the runtime libraries like libstdc++. See below. If --without-headers is indeed what you want, then make sure you specify the --target properly. If you include 'linux' in there, the build will fail trying to use glibc headers to build parts of libgcc that are Linux specific (or something like that), because--as stated before--the gcc is backasswards. If you need libc, I've seen people do 2 things, you should probably grab the libraries and headers from each target and put them (or build them on each target and install them) into a directory on your host machine; pass this directory to --with-sysroot during the configuration of gcc. That's my understanding. >> You then need to have the target libc in the appropriate level of the >> gcc src tree. Your error messages suggest to me you either don't have >> a libc build, or have it at the wrong level. I'm not sure this is correct. Take a look at --with-sysroot I have always only made "naked" (libc-less) cross compilers, but I believe that configuration switch should be hardcoded into the final gcc to tell it where to look for libc stuff (much in the same way I'd like to be able to configure gcc to look for binutils in some nonstandard place). > OK, this could very easily be the problem. I was assuming this was > built as a part of the gcc build, but that does not appear to be the > case. But if the compiler needs libc to build, and libc is built by > compiling.... which came first, the chicken or the egg? >> >> I found I couldn't build it "out the box" for the variants I was >> building for, I had to find and apply some patches. (Not too >> surprising, given the combinatorial explosion of host os X host CPU X >> target os X target CPU X libc implementation X libc version X >> binutils >> version, they simply can't test everything.) >> > I absolutely agree... there must be several thousand combinations. > I sometimes wonder if this works against the linux community rather > than for it? Against. Then again, Linux can't be built easily outside of standard Linuxy environments, as it too is backasswards, because it depends on other backasswards GNU setups. For instance, the kernel requires certain headers, like /etc/include/elf.h, but elf.h is only included with glibc. Then one must ask, why the hell would glibc concern itself with elf.h ? That should be part of binutils or something. >> Good Luck! I can email you my scripts for building things, can't >> guarantee they'll work for you though! Being in Ruby, I find them >> easy to >> read / maintain than the cross gcc shell script project. I have a Gentoo Linux box that is rather slow. I have a much faster PowerBook G4. Therefore, I wanted to use the PowerBook to compile stuff for use with the Gentoo box. Interestingly, distcc (which distributes compilation across machines) preprocesses code on the one client machine, so that only direct comp- ilation to Object Code is necessary on each server. This means the server need not have libraries or headers common to the client machine. For this reason, I built a naked cross compiler on the PowerBook: (or something similar) tar xjf binutils-2.17.tar.bz2 mv binutils-2.17 src mkdir build cd build export PREFIX=/usr/local/xgcc export TARGET=i686-elf ../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls make -j3 sudo make install -------------------------------- tar xjf gcc-core-4.1.2.tar.bz2 && tar xjf gcc-g++-4.1.2.tar.bz2 mv gcc-4.1.2 src mkdir build cd build export PATH=$PATH:$PREFIX/bin ../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls -- enable-languages=c,c++ --without-headers MACOSX_DEPLOYMENT_TARGET=10.4 make -j3 all-gcc sudo make install-gcc BUT! I had to link $PREFIX/bin/i686-elf-* to $PREFIX/bin/i686-pc-linux-gnu- *, because of backasswardsness; there is a gcc configuration switch to mangle the names, but this can cause problems if you configure binutils with mangled names too. I hope this helps / is correct. Sincerely, Michael Witten