Talk:GCC Cross-Compiler

Windows Subsystem for Linux

Checking in for the first time in a couple of years :) Just followed the instructions for apt-get based system on WSL (Bash on Ubuntu on Windows) and it works perfectly for gcc 6.2.0 with Binutils 2.27. I'll be switching to that system over Cygwin. --Aj 06:23, 25 November 2016 (CST)

Update to WSL

WSL has been non-beta for a while now and I'd suggest it as the go-to method for anybody using Windows 10 now. Compatibility with builds (grub tools etc...) is now so much better than Cygwin64 and I've been using it as my main dev environment on Windows 10 since the start of the Beta. I'm happy to add the relevant notes on the main wiki page. Objections? --Aj 05:54, 12 January 2018 (CST)

Repeatable Error with Cygwin 64?

I got a chance to have a play with my cross-compilers today (as you do...) and had a go at following the tutorial on the 64 bit version of Cygwin on Windows 8.1. Binutils version is 2.24 and GCC is 4.9.1, target is x86_64-elf. On "make install-gcc", I get the error:

Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc-4.9.0/gcc/doc/tm.texi.

I'm obviously not the first to get this error (reference). This seems to be some sort of file version control issue. In my case, copying the file as suggested by the error message did not work. What did work was to re extract the tar file containing the original GCC source, overwriting the GCC source files (I assume this resets date stamps). After this, I changed back to my build-gcc folder, ran 'make install-gcc' and the process went swimmingly. I can therefore confirm that the tutorial works OK in Cygwin64 with the above proviso. I've not added this to the list of common errors in the article as I don't have time to test repeatability and would like others to confirm that this is a real issue first. (PS: Diffutils also required as the build process uses cmp at this point) --Aj 16:49, 25 July 2014 (CDT)

PS: It also seems like in Cygwin64, the dependency libintl-devel is also not installed by default and needs to be added to Cygwin for successful compilation, even with --disable-nls. --Aj 06:29, 28 July 2014 (CDT)

Unwieldy Configurations Table Size

I've just added another working config and the table of "known good" configurations is now getting a little big when viewed on a 1024x768 4:3 monitor. The situation is only going to get worse, so could I make some suggestions:

1. Remove GCC versions < 4.0.0 and/or
2. Make the table reverse-chronological, so GCC 4.5.0 / Binutils 2.20 would be at the top left and version numbers would decrease rightwards and downwards, so no horizontal scroling for the latest version. and/or
3. Something else... and/or
4. Club together and buy me a nice widescreen monitor ;o)

Any thoughts, before I make such a big change? I favour option 2 (or 4!) so that all information is left intact --Aj 12:29, 11 February 2010 (UTC)

I support this, there should be a minimal resolution that all the articles should target.. most of my monitors are <= 1024x768, so that's my biased recommendation. --Brynet-Inc 03:00, 13 February 2010 (UTC)

I would go with option 1, since GCC4 is (AFAIK) fairly standard and mature now. If we go with option 1 however, I would also suggest dumping the other information regarding GCC3 from the article. Option 2 is an idea, but it won't decrease the size of the table and it's getting a bit big IMHO. --Creature 11:46, 13 February 2010 (UTC)

I don't agree with option 1, there still may be people using that version of the compiler. --Brynet-Inc 20:42, 13 February 2010 (UTC)

What if we were to split the table into two tables: one for GCC3 and one for GCC4? That would fix the exaggerated width and make it a little less overwhelming. --Creature 11:18, 14 February 2010 (UTC)

I have copied the table section to User:AJ/GCC_Cross-Compiler so that I can play around with the layouts. I won't do anything to the main article yet. I think this is such a well-used article that I will start a topic on the forums once I have a suggested replacement. --Aj 09:22, 15 February 2010 (UTC)

Building Target-libgcc

At the end of cross-compiler creation, I always run make all-target-libgcc install-target-libgcc for long long integer support and so on. I wonder if this should be added to the Cross-Compiler tutorial, as the sensible time to do this is when you already have a configured build directory. If so, how should it be added; perhaps just as a footnote or should it actually be listed as an (optional) additional build command at the end of the GCC build? --Aj 10:56, 3 August 2009 (UTC)

+1 for adding this to the tutorial. I think it would be best to keep it away from the bulk of the tutorial and leave it as a "Now you're done" sort of thing. That way people (especially those new to this kind of stuff) will be happy to leave with a cross-compiler without libgcc, and those who are interested in the additional features libgcc provides will read further. My 2c. --pcmattman 12:02, 3 August 2009 (UTC)

I have inserted this information before the troubleshooting section. The idea is that the libgcc targets should be built while the configured gcc directory still exists, so I hope to catch people before they close Bash and delete their temporary build-gcc directory. I have also added a link to a summary of libgcc and have deleted the (dead) link to bill gaitliff's site - he used to offer a free advice page, but now seems to provide commercial cross-compiler services under a different URL. --Aj 10:04, 25 August 2009 (UTC)

Compilation of x86_64-elf Target

I have just tried with GCC 4.3.1 and 4.3.2 and it appears that GCC no longer requires the x86_64-elf target adding manually for configuration (it now works in exactly the same way as i586-elf. I am going to make a few changes to the article to reflect this, but where does this leave the specific x86_64 Cross compiler article? Deleted? Added as a cross-reference for people building against older versions? --Aj 10:41, 29 September 2008 (UTC)

I would put that information in the x86_64 crosscompiler article, rather than adding it here, since people are told to go there anyway. - Combuster 10:58, 29 September 2008 (UTC)

Cross-Reference Suggestion

I was thinking of referencing the Porting Newlib article from Step 2 of this tutorial and/or the Articles section at the end of the page - any problems with that? --AJ 07:38, 1 October 2007 (CDT)

No problem at all. - Combuster 10:51, 1 October 2007 (CDT)

Binutils requires Flex & Bison

I'm editing the article because flex and bison are still required for at least binutils 4.2.2. CodeAnxiety 01:45, 31 January 2008 (CST)

What does it Do?

After reading through part 1, i fail to see what is done that cannot be done by GCC before creation of this cross compiler. It seems to be a waste of time, and nothing is specified about the platform that can't be accomplished by all other versions of GCC. --Tyler 22:50, 15 March 2007 (CDT)

Either your answer is in GCC_Cross-Compiler#Why_an_OS_developer_should_build_a_cross-compiler, otherwise, could you please be more clear in what the problem is exactly? - Combuster 04:03, 16 March 2007 (CDT)

My problem is... this tutorial does not show you how to "solve" any of these problems. It tells you how to recompile GCC to make only ELF files... something GCC can do anyway, ridding you of the problems. --Tyler 08:25, 16 March 2007 (CDT)

The main difference is that the GCC you are building is a Stage 1 toolchain, not a bootstrapped toolchain. (Not ELF vs COFF like you think) A dedicated crosscompiler does not think its compiling for windows/linux and as such does not fill in the gaps for you. It does just what you ask and only what you ask and nothing more, which is something you cant say of a stock GCC. Some of these 'features' you can override with commandline parameters, but some will stubbornly persist. - Combuster 04:45, 19 March 2007 (CDT)

Actually, the main difference is that, to my knowlegde, Cygwin GCC doesn't allow you to generate ELF binaries without the help of objcopy. Several other problems - like careless inclusion of system headers, error messages being posted to the forum that cannot be reproduced by people using a different host OS, and more - are also solved by this tutorial. Solar 09:57, 3 April 2007 (CDT)

Like Solar says, Cygwin GCC can't create ELF binaries by default. Creating a cross compiler fixes that, and more, and is pretty easily done. - Quok 20:30, 3 April 2007 (CDT)

Texinfo

Has anyone else had problems building Binutils/GCC when Texinfo is not installed? I am not sure what it is used for, but for some reason when not installed the Make fails. -- Tyler 14:02, 13 September 2007 (CDT)

AFAIK texinfo should only be used to make the documentation. On my setup, running 'make all-gcc' does not, by default, attempt to create the documentation and 'make install-gcc' does not attempt to install it, so texinfo shouldn't be required. Having said that, I do have texinfo installed, so I might not have noticed a call to it. John 14:41, 13 September 2007 (CDT)

I've never got as far as GCC without Texinfo, so i wouldn't know, it dies in the Binutils build, during a make all. Does Make all create documentation? -- Tyler 15:25, 13 September 2007 (CDT)

Yes, I'm afraid it does. There is a 'make all-binutils' command, but that also seems to try building in the bfd/doc directory. Apparently running configure with the --without-docdir option stops it trying to install the documentation. I don't know if it stops it trying to make it however. John 16:35, 13 September 2007 (CDT)

I checked my cygwin setup, and noticed texinfo is installed without me specifically selecting it, so it either is a dependency of one of the other packages I do have, or its installed by default. Since solar's regression test of removing, reinstalling, selecting the basic install + the packages listed always results in an environment that can build the crosscompiler, I don't think its an error in the tutorial. - Combuster 02:55, 14 September 2007 (CDT)

For those having problems building binutils without texinfo installed, run the configure step as normal. When that finishes, do this:

echo "MAKEINFO = :" >> Makefile

That command overrides the MAKEINFO variable in the Makefile, setting it to something that does not exist. This causes make to skip attempting to build (and subsequently install) the documentation. --quok 06:20, 26 August 2008 (UTC)

Version Junkies...

Pretty impressive to see how GCC 4.5.0 is listed in the "compatibility matrix", when it has not even hit ftp.gnu.org yet... someone *is* eager to use the latest... ;-) -- Solar 07:52, 12 February 2010 (UTC)

• I was thinking exactly the same thing... --Creature 17:19, 12 February 2010 (UTC)

GMP, MPFR and MPC

See Talk:Cross-Compiler_Successful_Builds and corresponding forum thread. These supporting libraries are general-purpose and not specific to your cross-compiling target, so it is best to install them the way your system usually installs packages, instead of compiling them from source. Which you can do properly only when you're root and remember to install to /usr/local, while no SysAdmin should have anything against installing them on a shared system you might be using.

RE: New "Note 2"

Quote: "Cygwin users should use the default Windows 'terminal'. Else you may get the error message <path-to-as>/as.exe: Bad Address". Can someone explain this one to me? This tutorial works fine in the Cygwin bash shell, as well as from the Windows 'cmd' shell (if the Cygwin /bin is in your PATH). This note seems misleading and misguided. --pcmattman 05:20, 13 December 2010 (UTC)

I cannot picture why this should be, either. I did send the user (whose only activity on either the Wiki and the forum was this edit) a PM on the forum asking him to elaborate, and reverted his edit until he does. -- Solar 10:03, 13 December 2010 (UTC)

On Mac OS X Lion

I was building a cross-compiler (binutils 2.22, gcc 4.6.2) for i386-elf on Mac OS X 10.7.2 with Xcode 4.1 using this tutorial (from memory at first, but I double checked to make sure that I wasn't screwing things up), when I came across a rather peculiar issue. The toolchain would successfully compile and install, but when I went to use it, it would start spewing out internal compiler errors. Below are the commands I used when building the toolchain, as well as a reduction for reproducing the errors.

export PREFIX=/usr/local/cross
export TARGET=i386-elf
export MAKEFLAGS="-j 16"
mkdir -p ~/src/build-{binutils,gcc}/
curl ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2 | tar -x -f - -C ~/src/
curl ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-core-4.6.2.tar.bz2 | tar -x -f - -C ~/src/
curl ftp://ftp.gnu.org/gnu/gmp/gmp-5.0.2.tar.bz2 | tar -x -f - -C ~/src/gcc-4.6.2/
curl ftp://ftp.gnu.org/gnu/mpfr/mpfr-3.1.0.tar.bz2 | tar -x -f - -C ~/src/gcc-4.6.2/
curl http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz | tar -x -f - -C ~/src/gcc-4.6.2/
cd ~/src/build-binutils/
../binutils-2.22/configure --prefix=$PREFIX --target=$TARGET --disable-nls
make all
sudo make install
export PATH=$PATH:$PREFIX/bin
cd ~/src/build-gcc/
mv ../gcc-4.6.2/gmp-5.0.2/ ../gcc-4.6.2/gmp/
mv ../gcc-4.6.2/mpfr-3.1.0/ ../gcc-4.6.2/mpfr/
mv ../gcc-4.6.2/mpc-0.9/ ../gcc-4.6.2/mpc/
../gcc-4.6.2/configure --prefix=$PREFIX --target=$TARGET --disable-nls --without-headers --with-mpfr-include=$HOME/src/gcc-4.6.2/mpfr/src/ --with-mpfr-lib=$HOME/src/build-gcc/mpfr/src/.libs/
make all-gcc
sudo make install-gcc

Source file (reduction.c):

void _start()
{
}

Built using:

i386-elf-gcc -ffreestanding -c reduction.c

Diagnostics:

reduction.c:3:1: internal compiler error: in execute_ipa_pass_list, at passes.c:1921
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Preprocessed source:

# 1 "reduction.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "reduction.c"
void _start()
{
}

After researching for a bit, I discovered that the issue is caused by Xcode 4.1's side-by-side installation of gcc, clang, and llvm-gcc.

$ readlink /usr/bin/gcc /usr/bin/g++
llvm-gcc-4.2
llvm-g++-4.2

By default, "gcc" will invoke llvm-gcc, which triggers some sort of bug in gcc's code (I didn't bother figuring out what specifically). To work around this, I set these variables at the beginning (along with PREFIX, TARGET, and MAKEFLAGS):

export CC=/usr/bin/gcc-4.2
export CXX=/usr/bin/g++-4.2
export CPP=/usr/bin/cpp-4.2
export LD=/usr/bin/gcc-4.2

And repeated the rest of the process as-is. Doing so creates a functional toolchain.

The reason I am posting this is because I suggest that these instructions be added to the tutorial, possibly in the Troubleshooting section. I'd go ahead and add it but I'm pretty new to the wiki and don't know if there's a change approval process or what. :) --Nokurn 05:47, 29 November 2011 (UTC)

Very good description of the problem. Thank you!

But I am confused. Your cross-compiler should reside in /usr/local/cross/bin, named i386-elf-gcc. (As your example call shows.) Whatever /usr/bin/gcc is or points to shouldn't affect it in the least. Neither should your CC / CXX / ... exports solve the problem...?!? -- Solar 07:11, 29 November 2011 (UTC)

$CC & co. are used when compiling the cross-compiler. Something about using llvm-gcc to produce the cross-compiler triggers a bug of some sort in the gcc source code, so you get a defective i386-elf-gcc. At least, that's what I've come to think. I don't know how else to explain why the host compiler would affect the resulting cross-compiler. I'd dig into the gcc source code to try to figure it out but I've heard so many horror stories about that codebase that I'm breaking into a cold sweat just by entertaining the idea... --Nokurn 07:18, 29 November 2011 (UTC)

Ah, I see - you set those exports while compiling the cross-compiler, not while using it (as I initially understood). That's definitely worth a bug report to upstream (GCC)... Funny enough, a quick Google shows that the animosities are mutual. :-D I'll extend the tutorial ASAP. -- Solar 14:58, 29 November 2011 (UTC)

I'll look into putting together a bug report for them. Thanks for adding it. Great tutorial by the way. --Nokurn 22:28, 29 November 2011 (UTC)

Multiple Versions Simultaneously

You can have multiple versions installed simultaneously by setting the --program-prefix and --program-suffix options during configuration. In my case I do --program-suffix=-$GCC_OR_BINUTILS_VERSION --program-prefix=$TARGET- where $GCC_OR_BINUTILS_VERSION is the version of gcc or binutils you are installing. - ChosenOreo

./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory AND TARGET=arm-linux-gnueabihf

I'm building the cross-compiler to start with for the bare target as this article outlines. I ran into a problem with the "make all-target-libgcc" step with the title error: ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory, occurring at some signification point in completion. I believe I've followed the steps verbatim. and; after research, even attempted to reconfigure with --disable-threads option. There's very little additional recommendation on this error that I've found beyond, using one of the many cross-compilers somebody else has generated. I think it would be great if this talk section could have comments And after a solution is found, a section in the main page added for the corrective actions. Thanks for any feedback. If an answer appears, I'd have no problem adding a minor change to the article assuming that's permitted.