GCC Cross-Compiler

Introduction

What is a cross-compiler?

Generally speaking, a cross-compiler is a compiler that runs on platform A (the "host"), but generates executables for platform B (the "target"). The two "platforms" might differ in CPU, operating system, and/or executable format.

Are you at the right place?

If...

• ...you are using Gentoo Linux,
• ...you want to do a cross-compiler for 64-bit (x86_64),
• ...you want to do a Canadian Cross,
• ...you want a cross-compiler for compiling applications (as opposed to hobbyist OS development covered here),

...please check the "Related Stuff" section at the bottom of this page.

Why an OS developer should build a cross-compiler

Creating a dedicated (cross-) compiler for your OS development work can save you many headaches. If...

• ...your system compiler drags in references to alloca() or other OS-dependent things,
• ...Cygwin complains about "PE operation on non-PE file",
• ...your compiler and your assembler can't agree on binary formats ("unresolved reference to _kmain()"), or
• ...your bootloader stubbornly insists that it cannot read your kernel binary,

the most effective solution is setting up a dedicated cross-compiler. If anything, it places you on the same playground as other users: You can rest assured that any problems you might yet encounter are not specific to your compiler setup.

Don't fear, it's easier than you might think.

How this document is organized

We describe a sequence of steps, starting with nothing but your system compiler and ending with a native compiler for the target system. You might not need all those steps (when you want to compile your hobbyist OS into a binary, Step 1 is all you need). Actually, at this point only Step 1 is actually covered.

Requirements

We assume you have a host system with a working GCC installation. If you are not using a bash shell, you might have to modify some of the command lines below. If you have just installed the basic Cygwin package, you have to run the setup.exe again and install the following packages:

• GCC
• Make
• Flex
• Bison

If you plan to use 4.3.0 or a later version, you will also have to install the following (see Building GMP):

• GMP
• MPFR

Note: Cygwin includes your Windows path in its bash path. This means that if you were using DJGPP before switching to Cygwin (in most cases, that is why you would want to build a GCC Cross-Compiler), you must either uninstall DJGPP first, or at least remove it from your PATH environment variable so the Cygwin tools get called instead of DJGPP. (After uninstalling DJGPP, you should delete the DJGPP environment variable and clear the C:\djgpp (or wherever you installed it) entry in your PATH to make sure everything's going to be all right.)

Tested on...

This has been tested to work with the below combinations of binutils and gcc:

	GCC 3.4.3	3.4.4	3.4.5	4.0.0	4.0.1	4.0.2	4.0.3	4.1.1	4.1.2	4.2.0	4.2.1	4.2.3	4.3.0	4.3.1
Binutils 2.16	Yes	Yes	Yes	Yes	Yes	Yes	Yes	?	?	?	?	?	?	?
2.16.1	Yes	Yes	Yes	Yes	Yes	Yes	?	Yes	?	?	?	?	?	?
2.17	?	Yes	?	?	?	?	?	Yes	Yes	Yes	?	?	?	?
2.18	?	?	?	?	?	?	?	?	?	?	Yes	Yes	Yes	Yes

It has also been tested successfully with various combinations of binutils 2.14 / 2.15 and GCC 3.2 / 3.3. The numbers refer to the versions being built, not the host compiler doing the build.

Problems have been reported on trying to build bintils 2.14 with Cygwin GCC < 3.3.3.3 as host compiler, as well as on trying to build binutils <= 2.15 with GCC 4.x as host compiler.

Step 1 - Bootstrap

We build a toolset running on your host that can turn source code into object files for your target system.

We need the binutils and the GCC packages from http://ftp.gnu.org/gnu/. Download them to /usr/src (or whereever you think appropriate), and unpack them.

You don't have to download the whole big gcc-x.x.x package - gcc-core is sufficient to build the C compiler. If you also want C++, download both gcc-core and gcc-g++, and unpack them in the same directory. (The remaining 12 megabyte or so in the main package are for Fortran, ADA, Java, Objective-C, and the test suite.)

Note: The versioning scheme used is that each fullstop seperates a full number, eg. 2.8.0 2.9.0 2.10.0 2.11.0, this may be confusing if you're used to Windows' program's schemes or even just basic math (eg. 1.01 1.02 etc).

Preparation

   export PREFIX=/usr/cross
   export TARGET=i586-elf
   cd /usr/src
   mkdir build-binutils build-gcc

The prefix will configure the build process so that all the files of your cross-compiler environment end up in /usr/cross, without disturbing your "normal" compiler setup.

binutils

   cd /usr/src/build-binutils
   ../binutils-x.xx/configure --target=$TARGET --prefix=$PREFIX --disable-nls
   make all
   make install

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

--disable-nls tells binutils not to include native language support. This is basically optional, but reduces dependencies and compile time. It will also result in English-language diagnostics, which the people on the Forum understand when you ask your questions. ;-)

gcc

Now, you can build GCC. (Use v3.3 or later - v3.2.x has a bug with internal __malloc declarations resulting in an error during compilation. This could be fixed by patching four occurrences in three different source files, but I lost the diff output and am not in a mind of re-checking. ;-) )

   cd /usr/src/build-gcc
   export PATH=$PATH:$PREFIX/bin
   ../gcc-x.x.x/configure --target=$TARGET --prefix=$PREFIX --disable-nls \
       --enable-languages=c,c++ --without-headers --with-newlib
   make all-gcc
   make install-gcc

The path has to be extended since GCC needs the binutils we built earlier at some point of the build process. You might want to add these extensions to your $PATH permanently, so you won't have to use fully qualified path names every time you call your cross-compiler.

--disable-nls is the same as for binutils above.

--without-headers tells GCC not to rely on any C library (standard or runtime) being present for the target.

--with-newlib is only necessary if you are compiling GCC <= 3.3.x. That version has a known bug that keeps --without-headers from working correctly. Additionally setting --with-newlib is a workaround for that bug.

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

Summary

Now you have a "naked" cross-compiler. It does not have access to a C library or C runtime yet, so you cannot use any of the standard includes or create runable binaries. But it is quite sufficient to compile your self-made kernel.

Usage

Once you are finished, your toolset resides in /usr/cross. For example, you have a gcc executable in /usr/cross/bin/$TARGET-gcc (and /usr/cross/$TARGET/gcc as well), which spits out binaries for your TARGET. Add /usr/cross/bin to your PATH environment variable, so that gcc invokes your system compiler, and $TARGET-gcc invokes your cross-compiler.

You could also use the -b and -V options of GCC. Let's assume you have a gcc 3.3.3 as system compiler (/usr/bin/gcc), and you just created a gcc 3.4.3 cross-compiler for i586-elf (/usr/cross/bin/i586-elf-gcc). Instead of calling i586-elf-gcc, you could also call gcc -b i586-elf -V 3.4.3...

This sounds strange at first, but it is rather simple: These options, passed to your system compiler, tell it that it's not really the system compiler you want - but rather the one for the target passed by the -b $TARGET option, and in the version passed by the -V $VERSION option. The system compiler turns these two options into a new executable name (namely gcc-$TARGET-$VERSION), and calls that one instead of compiling the source itself. Neat, huh? ;-)

Troubleshooting

i586-elf-ar not found

You forgot to set the executable path ($PATH) to include $PREFIX/bin.

Error: junk at end of line, first unrecognized character is ','

This, in combination with lots of other assembly-level error messages (like, Warning: .type pseudo-op used outside of .def/.endef ignored, or Error: unknown pseudo-op: '.local') results when you did not correctly set the --prefix=$PREFIX during the binutils configure.

Another possibility is that you did configure, compile and install your cross-compiler correctly, but don't actually use it. Check the "Usage" section above.

If you try compiling in 64-bit windows, you will receive a "Unknown host machine type" error when running configure. To fix this, scroll up in your shell until right after you entered the configure command and you will see a website which will show you where to download updated files to guess host type. Put them in the root directory of where your source files are located. With GCC version 3.4.0 you will have to override the host enviroment though, as it does not support being compiled with x86_64-unknown-cygwin . Add the command line argument --host=i686-unknown-cygwin to the configure line for GCC. --CjMovie (Too many edits to get this right...)

Configure: error: invalid feature name: nls

If you are using Cygwin, it must be set to use Unix/binary as the file mode. You can set this by running setup.exe and selecting the appropriate mode.

Step 2 - C Library

In the second step, we will build the C library for your target system.

The cross-compiler from Step 1 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!

The C standard defines two different kinds of executing environments - "freestanding" and "hosted". While the definition might be rather fuzzy for the average application programmer, it is pretty clear-cut when you're doing OS development: A kernel is "freestanding", everything you do in user space is "hosted".

A "freestanding" environment needs to provide only a subset of the C library: float.h, iso646.h, limits.h, stdarg.h, stdbool.h, stddef.h, and stdint.h (as of C99). All of these consist of typedef s and #define s "only", so you can implement them without a single .c file in sight.

You will probably want to add a "hosted" C library, so you can use all the nice #include s it provides. You have two choices - writing your own (not recommended, it's one big chunk of work all in its own), or porting an existing one.

You have to realize that a standard library needs to call the kernel in many places. While malloc() can pass out chunks of memory it manages internally, it has to call upon the kernel to actually get any memory it can manage. printf() sure can format your output, but it still has to call upon the kernel to actually print that output anywhere. fopen() does all the C-specific file management for you, but it has to call upon the kernel to actually provide access to a file. And so it goes on and on.

Well-known available C libraries are the GNU libc and newlib. Newlib is most likely the easier one to port. Another alternative would be building on PDPCLIB, or helping MartinBaute with the PDCLib (the latter one being aimed at maximum ease of portability for the very purpose of hobbyist OS development).

Once you have done that, go back to the above how-to, and recompile your GCC environment using the --with-headers option to tell it where to find the headers of your C library. You now have access to the standard library, but you still can't compile standalone executables, since you are still without a C (C++) runtime.

You can try the OS Specific Toolchain or Porting Newlib tutorials for help with porting a C library to your OS.

Step 3 - Full Cross-Compiler

In the third step, we will build a "complete" cross-compiler, which can create not only object files, but standalone executables. For that, you will need a C (C++) runtime that sets up the process environment for an executable, i.e. all the stuff that happens before int main(). This is highly platform-specific, so we can only give an overview of the steps involved.

See OS Specific Toolchain for a tutorial on creating a full cross compiler.

Step 4 - Native Compiler

In the fourth step, we will "bootstrap" a native GCC, that not only compiles for the target, but also runs on the target. This is basically the ticket for leaving your host OS behind, and doing all your development work on your own OS! (Of course, you need an editor and a shell environment to actually enjoy this, but you sure did that first thing after finishing Step 3 above, didn't you...?)

...to be extended. This is the only place where --disable-shared really makes sense.

The --disable-shared option

This is an option to the GCC configure process that you might or might not use. It's a bit tricky...

with --disable-shared...

...every single executable in your cross-compiler environment will be statically linked, which makes them huge. On the other hand, you can move around those executables, as there are no dependencies (which is what you want in step 4 above, to "bootstrap" your first native compiler). However, if you compiled any of the libraries that are linked in with a more advanced -march, the resulting executable is going to be only for that arch or better. This is usually no problem - unless you're doing a Canadian Cross where you might want to put the executable on a slower (less-featured) machine. Bad luck...

without --disable-shared...

...the executables will use dynamic linking, and will be much smaller. Now comes the tricky part: Not only the system libraries are dynamically linked, but also those implementing generic functionality of the cross-compilation environment. This is done by hard-coding the library paths into the executables... meaning that you can not move them to another directory. This is usually not necessary - unless you're doing a Canadian Cross where you might want to build the executables in a directory different from the one you want to install them in (e.g. due to access limitations on the build machine). Bad luck...

For a Canadian Cross, the best idea is not to use the option, and to copy the file to the exact same directory.

See Also

Articles

• GCC Cross-Compiler for x86_64 - making things 64-bit.
• Canadian Cross - making things yet more complicated.
• Porting Newlib - porting a C standard library for use with your cross-compiler.
• OS Specific Toolchain - going a step further and adding your own target.
• GCC Cross-Compiler on Linux - some distros make things much easier.

External Links

• http://kegel.com/crosstool has a popular example of a script that automatically downloads, patches, and builds binutils, gcc, and glibc for known platforms.
• http://crossgcc.billgatliff.com/ is Bill Gatliff's CrossGCC FAQ. <This link appears to be dead>
• http://forums.gentoo.org/viewtopic.php?t=66125 - Compiling Windows applications under Linux
• http://www.libsdl.org/extras/win32/cross/README.txt - dito