Re: Cross compilation settings

[Ralf Corsepius]

On Fri, 2004-02-06 at 12:39, Mario Luca Bernardi wrote:
> Hi ,
> i'm working on a project that have 3 target platform and i'm using GNU
> Autotools. The project should always be built on i686-pc-linux-gnu but
> have to be run on the following hosts:
> 
> 1) i686-linux-pc-gnu (without cross compilation)  
> 
> 2) arm-linux [ Cross-compilation with arm-linux-gcc and GCC tools only ]
> 
> 3) arm-epoc-pe [ Cross-compilation with arm-epoc-pe-gcc and some other
> tools ]
> 
> The 1) and 2) point are ok since i can in both cases to build the
> sources ( i'm using AC_CANONICAL_SYSTEM in configure.ac and pass to
> configure the proper --build and --host).
> For 3) i'm having some problems since the build process is more complex.
> In this case arm-epoc-pe-gcc must always get a .o file from a .c or .cpp
> source code and the linking step must be done after with some other
> tools that use other intermediate files. To simplify a bit:
> 
> main.cpp--[GCC]-->.o--[dlltool]-->.def1-->.bas--[dlltool]->.exp--[ld]-->.exe
>                                                                   |
>                              [Some External Libraries]------------|
> 
> Since the linking is done completely outside arm-epoc-pe-gcc it can't
> generate executables[moreover it lacks of all crt*.o object files]. In
> my configure.ac there is AC_PROG_CC and when i run configure it checks
> what is the name of default executable for the C compiler. That's cause
> the config to fail building a test to determine the default executable
> name ( config.log show an ld error [ can't find crt0.o ] ). How i can
> fix that ?
Fix your gcc. More precisely: Change gcc in such a way that it can link.
This normally means to supply a startup file (crt.o).

There are cases where this is difficult (bootstrapping gcc, libc or an
OS).
 
>  There is a way to specify that the compiler in case 3) should
> never used to generate executables?
Do you expect executable to fall out of the sky? :)

There exist several ways to work around these problems:
* extend gcc to do what you what it to do.
* Pass appropriate flags (CC="gcc-<target>
--startfile=/somewhere/start.o --nostdinc -L/somewhere/ --spec myspec
..." or similar)
* Use a wrapper script.
* If using automake, override automake's linker related make-variables.

What might be applicable to you depends on your particular
problem/situation.

>  Moreover there is a way to have the
> above behaviour for building sources in the case 3) and a standard
> gcc executable generation on case 1) and 2) ?

You don't really want to do that ;)

Ralf