GCC Cross-Compiler: Difference between revisions

{{rating|1}}

This tutorial focuses on creating a GCC cross-compiler for your own operating system. This compiler that we build here will have a generic target (i686-elf) that allows you to leave the current operating system behind, meaning that no headers or libraries of the host operating system will be used. Without using a cross-compiler for operating system development, a lot of unexpected things can happen because the compiler assumes that the code is running on the host operating system.

This command prints the current compiler version:

 

 

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.

{{Main|Cross-Compiler Successful Builds}}

The latest and greatest [[Binutils]] release is recommended. Note, however, that not all combinations of GCC and Binutils work. If you run into trouble, use a Binutils that was released at roughly the same time as your desired compiler version. You probably need at least Binutils 2.22, or preferably the latest 2.23.2 release. It doesn't matter what Binutils version you have installed on your current operating system. This command prints the binutils version:

 

=== Deciding on the target platform ===

 

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

Instead you should build it yourself with <tt>arm-none-eabi</tt> being the $TARGET.

 

=== 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.

=== GDB ===

 

 

The protocol for building GDB to target a different architecture is very similar to that of regular Binutils:

 

../gdb.x.y.z/configure --target=$TARGET --prefix="$PREFIX" --disable-werror

make all-gdb

make install-gdb

 

 

=== 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.

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.

 

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.

* [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)

 

* [https://drive.google.com/file/d/1zn37YmyVrtsPOfe88jZRZ_-_3_jzpXBP/view?usp=sharing i686-elf 13.1.0 target] ('''Important: extracts to a directory called "cross-tk"''')