Code compiled by GNU CC uses certain runtime support functions implicitly. Some of these functions can be compiled successfully with GNU CC itself, but a few cannot be. These problem functions are in the source file `libgcc1.c'; the library made from them is called `libgcc1.a'.
When you build a native compiler, these functions are compiled with some other compiler--the one that you use for bootstrapping GNU CC. Presumably it knows how to open code these operations, or else knows how to call the run-time emulation facilities that the machine comes with. But this approach doesn't work for building a cross-compiler. The compiler that you use for building knows about the host system, not the target system.
So, when you build a cross-compiler you have to supply a suitable library `libgcc1.a' that does the job it is expected to do.
To compile `libgcc1.c' with the cross-compiler itself does not work. The functions in this file are supposed to implement arithmetic operations that GNU CC does not know how to open code for your target machine. If these functions are compiled with GNU CC itself, they will compile into infinite recursion.
On any given target, most of these functions are not needed. If GNU CC can open code an arithmetic operation, it will not call these functions to perform the operation. It is possible that on your target machine, none of these functions is needed. If so, you can supply an empty library as `libgcc1.a'.
Many targets need library support only for multiplication and division.
If you are linking with a library that contains functions for
multiplication and division, you can tell GNU CC to call them directly
by defining the macros MULSI3_LIBCALL, and the like. These
macros need to be defined in the target description macro file. For
some targets, they are defined already. This may be sufficient to
avoid the need for libgcc1.a; if so, you can supply an empty library.
Some targets do not have floating point instructions; they need other functions in `libgcc1.a', which do floating arithmetic. Recent versions of GNU CC have a file which emulates floating point. With a certain amount of work, you should be able to construct a floating point emulator that can be used as `libgcc1.a'. Perhaps future versions will contain code to do this automatically and conveniently. That depends on whether someone wants to implement it.
Some embedded targets come with all the necessary `libgcc1.a' routines written in C or assembler. These targets build `libgcc1.a' automatically and you do not need to do anything special for them. Other embedded targets do not need any `libgcc1.a' routines since all the necessary operations are supported by the hardware.
If your target system has another C compiler, you can configure GNU CC as a native compiler on that machine, build just `libgcc1.a' with `make libgcc1.a' on that machine, and use the resulting file with the cross-compiler. To do this, execute the following on the target machine:
cd target-build-dir ./configure --host=sparc --target=sun3 make libgcc1.a
And then this on the host machine:
ftp target-machine binary cd target-build-dir get libgcc1.a quit
Another way to provide the functions you need in `libgcc1.a' is to
define the appropriate perform_... macros for those
functions. If these definitions do not use the C arithmetic operators
that they are meant to implement, you should be able to compile them
with the cross-compiler you are building. (If these definitions already
exist for your target file, then you are all set.)
To build `libgcc1.a' using the perform macros, use
`LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler.
Otherwise, you should place your replacement library under the name
`libgcc1.a' in the directory in which you will build the
cross-compiler, before you run make.
Go to the first, previous, next, last section, table of contents.