f78
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 libgccl.a.
When you build a native compiler, these functions are compiled with some other compilerthe 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 doesnt 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 ./configurehost=sparctarget=sun3 make libgcc1.aAnd then, execute the following on the host machine:
ftp target-machine binary cd target-build-dir get libgcc1.a quitAnother 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. 0