Re: Once more cross compilation

[Nicola Pero]

> As I stated in the last mail I think that GNUstep make mixes up the 
> three different computer system involved in a cross compilcation. There 
> are BUILD, HOST and TARGET.

Yes


> A few examples:
> - Most often all three systems are the same.
> - When compiling for MinGW in a Cygwin environment BUILD and HOST are 
> Cygwin whereas Target is MINGW.

so you should use HOST = cygwin and TARGET = mingw in this case


> - When compiling GNUstep on a Intel Linux machine to run it on a Zaurus 
> ARM processor BUILD is x86-* and HOST and Target both are arm-*.

so you should use HOST = arm and TARGET = arm ... but then you are
building gnustep-make on x86-*, but you can't use it on x86-*.  you have
to use it on arm (becase HOST is arm)!

Btw, if you are using HOST=arm, then why not using BUILD=arm as well?

To use gnustep-make on arm (which is what HOST=arm means), you need a
plethora of tools, including make, shells, compilers. linkers.  At which
point you might as well build it directly on arm (BUILD=arm), since those
tools are exactly what you need to build it.

More likely what you want to do is:

 * build gnustep-make on x86, setting HOST and TARGET to arm to have a
gnustep-make which you can use on arm

 * build a second gnustep-make on x86, setting HOST to x86 and TARGET to 
arm to have a gnustep-make which you can use on x86 to compile other 
gnustep packages for arm

 * install on arm the first gnustep-make, and the arm packages generated 
by the second gnustep-make

If this doesn't work (which likely doesn't), then there might something to
fix.  But hopefully it's nothing radically wrong :-)


> But this is only a minor problem, compared to the fact that I 
> think almost everywhere in the GNUstep make files and make helpers that 
> BUILD should be used in place of HOST. For example ld_lib_path.sh uses 
> only HOST, but never BUILD to determine and even common.make uses 
> $(GNUSTEP_MAKEFILES)/$(GNUSTEP_HOST_CPU)/$(GNUSTEP_HOST_OS)/which_lib to 
> find which GNUstep libraries to link. Of course this fails as soon as 
> HOST!=BUILD.

Why ?

which_lib should be looked up in HOST.  It's in HOST that you run/use
gnustep-make.  BUILD is only where you originally built it.



> When cross compiling GNUstep you first build make for the BUILD and than 
> for the TARGET, so this would work with HOST replaced by BUILD. And this 
> is what I suggest, replacing HOST with BUILD in most make files.

I appreciate you looking into this, but I don't think this is correct
though.

If you are cross compiling with BUILD, HOST and TARGET, you would build
gnustep-make on BUILD, configured to run on HOST (which might or might not
be the same as BUILD), configured to compile stuff for TARGET (which might
or might not be the same as HOST).

Then, the libobjc flags should be the ones required by the compiler on
HOST to produce ObjC stuff for TARGET.  The which_lib.c executables should
be compiled to run on HOST (which might be different from the local BUILD
system).  All look ups in makefiles etc looking for scripts or tools used
to build should be done so that they run on HOST, because you are supposed 
to run gnustep-make on HOST.

BUILD is only used while doing a ./configure or make/make install of
gnustep-make itself, and never again; when you run gnustep-make, that will
happen on HOST (by definition of BUILD and HOST) -- after you have
manually (presumably) copied the gnustep-make installation from BUILD onto
HOST.

I'm quite happy if you try out the cross-compiling, and I'd like to thank
you for looking into this.  I apologize for the late response.

I'm quite sure there are details to improve.

Thanks