GCC Cross-Compiler: Difference between revisions

{{rating|1}}

 

== Introduction ==

 

 

=== Why cross-compilers are necessary ===

{{Main|Why do I need a Cross Compiler?}}

 

 

=== Which compiler version to choose ===

{{Main|Building GCC}}

 

 

You can also use older releases as they are usually reasonably good. If your local system compiler isn't too terribly old (at least GCC 4.6.0), you may wish to save yourself the trouble and just pick the latest minor release (such as 4.6.3 if your system compiler is 4.6.1) for your cross-compiler.

 

 

 

You may be able to use an older major GCC release to build a cross-compiler of a newer major GCC release. For instance, GCC 4.7.3 may be able to build a GCC 4.8.0 cross-compiler. However, if you want to use the latest and greatest GCC version for your cross-compiler, we recommend that you [[Building GCC|bootstrap the newest GCC]] as your system compiler first. Individuals using OS X 10.7 or earlier might want to invest in either building a system GCC (that outputs native Mach-O), or upgrading the local LLVM/Clang installation. Users with 10.8 and above should install the Command Line Tools from Apple's developer website and use Clang to cross-compile GCC.

=== Which binutils version to choose ===

{{Main|Cross-Compiler Successful Builds}}

 

=== Deciding on the target platform ===

 

=== Note on arm-none-eabi-gcc ===

 

== Preparing for the build ==

=== Preparation ===

 

export PREFIX="$HOME/opt/cross"

export TARGET=i686-elf

export PATH="$PREFIX/bin:$PATH"

 

We add the installation prefix to the <tt>PATH</tt> of the current shell session. This ensures that the compiler build is able to detect our new binutils once we have built them.

# But reconsider: You should just get the development packages from your OS.

-->

cd $HOME/src

 

make

make install

 

This compiles the binutils (assembler, disassembler, and various other useful stuff), runnable on your system but handling code in the format specified by $TARGET.

 

'''--with-sysroot''' tells binutils to enable sysroot support in the cross-compiler by pointing it to a default empty directory. By default, the linker refuses to use sysroots for no good technical reason, while gcc is able to handle both cases at runtime. This will be useful later on.

 

=== GCC ===

-->

 

cd $HOME/src

 

make install-gcc

make install-target-libgcc

 

We build [[libgcc]], a low-level support library that the compiler expects available at compile time. Linking against [[libgcc]] provides integer, floating point, decimal, stack unwinding (useful for exception handling) and other support functions. Note how we are ''not'' simply running <tt>make && make install</tt> as that would build way too much, not all components of gcc are ready to target your unfinished operating system.

'''--enable-languages''' tells [[GCC]] not to compile all the other language frontends it supports, but only C (and optionally C++).

 

 

If you are building a cross compiler for x86-64, you may want to consider building Libgcc without the "red zone": [[Libgcc_without_red_zone]]

== Using the new Compiler ==

 

 

You can now run your new compiler by invoking something like:

 

 

Note how this compiler is ''not'' able to compile normal C programs. The cross-compiler will spit errors whenever you want to #include any of the standard headers (except for a select few that actually are platform-independent, and generated by the compiler itself). This is quite correct - you don't have a standard library for the target system yet!

 

 

To use your new compiler simply by invoking <tt>$TARGET-gcc</tt>, add <tt>$HOME/opt/cross/bin</tt> to your <tt>$PATH</tt> by typing:

 

 

This command will add your new compiler to your PATH for this shell session. If you wish to use it permanently, add the PATH command to your <tt>~/.profile</tt> configuration shell script or similar. Consult your shell documentation for more information.

==== Binutils 2.9 ====

 

 

==== Building GCC: the directory that should contain system headers does not exist ====

 

The solution is simply to create the empty folders:

mkdir -p $SYSROOT/mingw/include

mkdir -p $SYSROOT/mingw/lib

 

This will allow the build to proceed. The reason this happens is that the <tt>mingw32</tt> (and mingw itself) configures <tt>INCLUDE_PATH</tt> and <tt>LIBRARY_PATH</tt> to be, as can be guessed, <tt>/mingw/include</tt> and <tt>/mingw/lib</tt>, instead of the defaults <tt>/usr/include</tt> and <tt>/usr/lib</tt>. Why the build fails even though nothing is required in those folders, and why it doesn't just make them, is beyond me.

 

== More advanced ==

 

'''For Linux i686 host'''

* [https://drive.google.com/open?id=13Kg6Xd8acUnwUoZQBTOjwAQQeGOeYzVz i386-elf 9.3.0 target]

* [https://drive.google.com/open?id=1g9jzEIn8CB6ZiVrc0uxbZprepcX4gYex i686-elf 9.3.0 target]

* [https://drive.google.com/open?id=10UuOf9LW4y9WEJcTWrMZW0GAlOWh9KG7 mips64-elf 9.3.0 target]

* [https://drive.google.com/open?id=1H3Cbq4D_kjROB-7Otiisa-mac_9FYUM- powerpc-elf 9.3.0 target]

* [https://drive.google.com/open?id=1XzQDKTK35EX8b380bPRbuhX1GPKrtI77 sparc-elf 9.3.0 target]

 

'''For Linux x86_64 host'''

* [https://drive.google.com/file/d/0Bw6lG3Ej2746STJaM2dNbC05elE/view?usp=sharing i386-elf & i686-elf 7.1.0 target uploaded by TheAlmostGenius]

 

 

The packages from phillid.tk below have been shrunk to about 10 MiB for each pair of packages (GCC &amp; Binutils).

* [https://drive.google.com/file/d/0B85K_c7mx3QjUnZuaFRPWlBIcXM/edit?usp=sharing i686-elf 4.8.2 target]

* [https://mega.co.nz/#F!bBxA3SKJ!TDL4i1NjaZKd4YMo9p2U7g x86_64-elf 5.1.0 target]

 

'''For Windows Subsystem for Linux (Beta) host'''

* [http://www.bin-os.com/i686-elf-6.1.0.tar.gz i686-elf 6.1.0 target] (extracts to a directory called "cross", don't forget to install 'make' - I would recommend "apt-get install build-essential" to also add additional useful tools)

 

 

 

'''ARM prebuilt toolchains for multiple host platforms'''