Re: Cocotron used for a real-world app

[address@hidden]

On 3 Nov., 10:43, Fred Kiefer <fredkie...@gmx.de> wrote:
> Markus Hitter wrote:
>
> > Am 02.11.2008 um 23:58 schrieb Fred Kiefer:
>
> >> Doing a configure for cross compilation is bound to fail
>
> > Why? My gcc experience is a bit dated, but in the Mac OS X 10.0 days,
> > gcc could configure for cross-targets almost fine already. What you need
> > is a copy of the foreign (MinGW-)environment, of course.
>
> > The difficult part is to distinguish between binaries meant to run in
> > the build process (helper tools) and binaries meant to run on the other
> > architecture. But gcc's configure has mechanisms to deal with this in
> > place, even if they might be somewhat buggy (rarely tested).
>
> > I can't see a reason why GNUstep's configure couldn't do this as well.
>
> The big difference between gcc and GNUstep is that the former doesn't
> rely heavily on external libraries. So configuring gcc itself for cross
> compilation isn't that hard. For GNUstep we need to know a lot more
> about the environment is is compiled in.
>
> I would say there are cases which will work and others that wont. We use
> configure to find out about installed libraries and headers, this might
> work, but we also try to find out whether some functions are actually
> provided by those libraries and working. To do so configure needs to
> build and run short code fragments and the later part just wont work.
> What is possible is to provide the correct values as configure command
> line arguments, but then already providing the full config.h file for
> Windows might be easier.
>
> On the other hand, my experience with cross compilation is a bit dated
> as well and they may be better way to do this now.
>
> Fred

I am not experienced with Cross-Compiling for Windows but the mySTEP
projects has provided a lot of insights about cross-compiling GNUstep
on
MacOS X.

1. installing a working gcc on OS X isn't simple. Especially if you
want to have the linux and glibc headers. The reason is that they have
so many assumptions about the underlying system where OS X and
Linux differ. It starts with the correct gmake (instead of make) and
goes
through ./configure packages that check the version of the host gcc,
ld,
as - where Apple provides version numbers that are outdated from the
view of the package. So you need some wrappers that provide faked
version numbers.

So, simply getting e.g. the glibc headers and doing a

   ./configure; make install-headers

fails.

2. as Fred points out, cross-compiling needs a set of runtime
libraries and
header files for the target architecture. But we need a copy on the
host system.

So the SDK must include a full set of Linux, libjpeg, libfftype,
libX11 etc.
includes and libs compatible to the target machine

3. Fred mentiones some tools that are run at compile-time. These need
to run natively on OS X.

4. a Plugin for Xcode is simple. I just have a makefile that processes
some environment variables. So I just add a new "Shell Script Build
Phase"
to some project target and define the variables and finally call make.

5. There can be archtecure dependent parts in the objc runtime or
in some foundation classes (the ARM processor e.g. uses a Mixed-Endian
format for double floats. So, swapping Network to Host byte order for
external communication needs additional code). But these are quite
rare
and are easily handled by #ifdef.

So in my experience, getting the cross-compilation environment is the
complex part. And I still have not solved it for ARM-EABI which is the
reason why there is no QuantumSTEP for the Openmoko Freerunner yet
(David, I know you are waiting).

BR,
Nikolaus