Why do I need a Cross Compiler?: Difference between revisions

m
→‎Articles: add zig cc
[unchecked revision][unchecked revision]
(+Notice that this is specific to GCC)
m (→‎Articles: add zig cc)
 
(4 intermediate revisions by 4 users not shown)
Line 5:
It is possible ask your compiler what target platform it is currently using by calling the command:
 
<sourcesyntaxhighlight lang="bash">
gcc -dumpmachine
</syntaxhighlight>
</source>
 
If you are developing on 64-bit Linux, then you will get a response such as 'x86_64-unknown-linux-gnu'. This means that the compiler thinks it is creating code for Linux. If you use this GCC to build your kernel, it will use your system libraries, headers, the Linux [[libgcc]], and it will make a lot of problematic Linux assumptions. If you use a [[GCC_Cross-Compiler|cross-compiler]] such as i686-elf-gcc, then you get a response back such as 'i686-elf' that means the compiler knows it is doing something else and you can avoid a lot of problems easily and properly.
Line 38:
 
=== Options you should link with ===
These options only make sense when linking (not when compiling) and you should use them. You should pass the compilation options as well when linking, as some compilation options (such as <tt>-mno-red-zone</tt>) control the ABI and this needs to be known at link time as well).
 
==== -nostdlib (same as both -nostartfiles -nodefaultlibs) ====
Line 75:
The compiler assumes it is targetting your local system, so you need a lot of options to make it behave. A trimmed down command sequence for compiling a kernel without a cross-compiler could look like this:
 
<sourcesyntaxhighlight lang="bash">
as -32 boot.s -o boot.o
gcc -m32 kernel.c -o kernel.o -ffreestanding -nostdinc
gcc -m32 my-libgcc-reimplemenation.c -o my-libgcc-reimplemenation.o -ffreestanding
gcc -m32 -T link.ld boot.o kernel.o my-libgcc-reimplemenation.o -o kernel.bin -nostdlib -ffreestanding
</syntaxhighlight>
</source>
 
Actually, the average case is worse. People tend to add many more problematic or redundant options. With a real cross-compiler, the command sequence could look this this:
 
<sourcesyntaxhighlight lang="bash">
i686-elf-as boot.s -o boot.o
i686-elf-gcc kernel.c -o kernel.o -ffreestanding
i686-elf-gcc -T link.ld boot.o kernel.o -o kernel.bin -nostdlib -ffreestanding -lgcc
</syntaxhighlight>
</source>
 
=== Reimplementing libgcc ===
Line 99:
You need to pass even more options to the command lines that build programs for your operating systems. You need a -Ipath/to/myos/include and -Lpath/to/myos/lib to use the C library, and more. If you set up an [[OS Specific Toolchain]], you just need
 
<sourcesyntaxhighlight lang="bash">
i686-myos-gcc hello.c -o hello
</syntaxhighlight>
</source>
 
to cross-compile the hello world program to your operating system.
Line 122:
=== What are the basics of cross compiling? ===
 
The "build" machine is the machine you're compiling the software on. This software being compiled may be compiled to run on some other type of machine. See, you may be building on an x86-based machine, and wishing for the software to run on a SPARC based machine. The build machine is implicit and will usually be auto-detected by the configure script for the software. Its only real purpose is so that, if the software being compiled chooses to keep the configure arguments used to configure it somewhere in the built package, the people to whom the package is distributed will know what machine the package was built on. The name of the build machine may be used to configure tothe package to use workarounds as well if the build machine is universally known to have certain problems building that software.
 
The "host" machine is the machine on which the software must run. So in the previous example, the "build" machine is an i686-elf-yourBuildOs machine, and the host is a sparc32-elf-unix4 machine.
Line 173:
* [[GCC Cross-Compiler]]
* [[Cross-Porting Software]]
* [["zig cc" Cross-Compiler]]
 
[[Category:Compilers]]
[[Category:FAQ]]
[[Category:OS_Development]]