GCC Cross-Compiler: Difference between revisions

Jump to navigation Jump to search
m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
m (Reverted edits by Melina148 (talk) to last revision by Moltony112)
m (Bot: Replace deprecated source tag with syntaxhighlight)
Line 21:
This command prints the current compiler version:
 
<sourcesyntaxhighlight lang="bash">gcc --version</sourcesyntaxhighlight>
 
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.
Line 28:
{{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:
<sourcesyntaxhighlight lang="bash">ld --version</sourcesyntaxhighlight>
 
=== Deciding on the target platform ===
Line 53:
=== Preparation ===
 
<sourcesyntaxhighlight lang="bash">
export PREFIX="$HOME/opt/cross"
export TARGET=i686-elf
export PATH="$PREFIX/bin:$PATH"
</syntaxhighlight>
</source>
 
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.
Line 71:
# But reconsider: You should just get the development packages from your OS.
-->
<sourcesyntaxhighlight lang="bash">
cd $HOME/src
 
Line 79:
make
make install
</syntaxhighlight>
</source>
 
This compiles the binutils (assembler, disassembler, and various other useful stuff), runnable on your system but handling code in the format specified by $TARGET.
Line 93:
The protocol for building GDB to target a different architecture is very similar to that of regular Binutils:
 
<sourcesyntaxhighlight lang="bash">
../gdb.x.y.z/configure --target=$TARGET --prefix="$PREFIX" --disable-werror
make all-gdb
make install-gdb
</syntaxhighlight>
</source>
 
The <tt>'''--disable-nls'''</tt> and <tt>'''--with-sysroot'''</tt> options don't seem to have any effect.
Line 117:
-->
 
<sourcesyntaxhighlight lang="bash">
cd $HOME/src
 
Line 130:
make install-gcc
make install-target-libgcc
</syntaxhighlight>
</source>
 
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.
Line 150:
You can now run your new compiler by invoking something like:
 
<sourcesyntaxhighlight lang="bash">$HOME/opt/cross/bin/$TARGET-gcc --version</sourcesyntaxhighlight>
 
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!
Line 160:
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:
 
<sourcesyntaxhighlight lang="bash">export PATH="$HOME/opt/cross/bin:$PATH"</sourcesyntaxhighlight>
 
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.
Line 185:
 
The solution is simply to create the empty folders:
<sourcesyntaxhighlight lang="bash">
mkdir -p $SYSROOT/mingw/include
mkdir -p $SYSROOT/mingw/lib
</syntaxhighlight>
</source>
 
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.
Cookies help us deliver our services. By using our services, you agree to our use of cookies.

Navigation menu