discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cross-compiling & distributing Tools


From: Michael Hopkins
Subject: Cross-compiling & distributing Tools
Date: Sun, 04 Jun 2006 19:46:37 +0100
User-agent: Microsoft-Entourage/11.2.3.060209


Hi all

I am going to ask some questions here which have been posed at various times
in the past by both me and others (here and in other places), but they never
seem to get clear, authoritative answers for some reason. I am hoping that
this attempt will connect with the people who really know and can provide
solid advice and pointers for others to follow.

We are hoping to wrap a bunch of our C math code into flexible interacting
objects and would prefer to use Objective-C/Foundation over C++/STL, but
unless we can get to the bottom of the following issues, we realistically
won't be able to do it.

First, some clarification of what we are trying to achieve & how:

- Building GNUstep Tools i.e. non-GUI Objective-C code that just relies upon
GNUstep-base <-> Foundation

- Build machine is Ubuntu 6.06 amd64 with it's GNUstep development installs:

 gnustep-base-* 1.11.2-1
 libgnustep-base(& -dev) 1.11.2-1
 gnustep-make 1.11.2-1

The standard build environment is working fine.


Now the crux of this message:

***************************************************************************
1) Cross-compiling without headaches - supposedly one of the main reasons
for gnustep-make.  
***************************************************************************

Though we develop on Mac OS X (due to the lovely Xcode), the native target
for running code & distribution builds is GNU/Linux amd64.  Our other two
targets are GNU/Linux i386 (i.e. 32 bit) and Win32 via mingw32.

Our current solution for C & C++ code uses BSD make (pmake) for historical
reasons and calls different tools dependent upon command line options i.e.

Target=amd64 ->
 CC = /usr/bin/gcc
 CFLAGS = -march=athlon64 -mtune=athlon64 -m64 ...

Target=linux32 ->
 CC = /usr/bin/gcc
 CFLAGS = -march=pentium4 -mtune=pentium4 -m32 ...

Target=win32 ->
 CC = /usr/bin/i586-mingw32msvc-gcc
 CFLAGS = -march=pentium4 -mtune=pentium4  ...

Along with other supporting library & include makefiles this works well and
finds requirements/installs products correctly.

Now - how to do this with GNUstep make?

>From the INSTALL doc:
============================================================================
Configuring for a non-flattened structure
-----------------------------------------

GNUstep is normally configured to support a single target/combo. If you
are interested in supporting more than one target and/or combo, it's
possible to configure GNUstep to use a non-'flattened' directory
structure.  You do this by supplying the `--disable-flattened' argument
to configure.  You might also want to supply the
`--enable-multi-platform' option.

   In a flattened structure, files are stored at the top-level rather
than in a `$(GNUSTEP_CPU)/$(GNUSTEP_OS)/$(LIBRARY_COMBO)' subdirectory.

Configuring for a cross-compile target
--------------------------------------

By default when you run configure, it assumes that you want to create
executables for the same host that you are compiling on; however, the
GNUstep makefile package has been designed to support cross-compiling
just as easily as normal compiling.  In order to add a cross-compile
target to the GNUstep makefile package, you must rerun configure for
that target and reinstall the makefile package.  By rerunning
configure, the appropriate target settings are determined, and
reinstalling the makefile package installs the appropriate files for
that target.  The target parameter is used to specify the target
platform for cross-compiling:

     ./configure --target=i386-mingw32
     make install

   GNUstep normally is configured to work with only one target. To work
with multiple targets, you'll need to add `--disable-flattened' and
`--enable-multi-platform' to the configure flags.  Files for the
different targets will not be overwritten when you configure and install
the make package several times.

     ./configure --disable-flattened --enable-multi-platform
--target=i386-mingw32
     make install
     ./configure --disable-flattened --enable-multi-platform
--target=sparc-solaris2.5
     make install
     ./configure --disable-flattened --enable-multi-platform
--target=alpha-linux-gnu
     make install
============================================================================

OK, so this describes how to configure and build gnustep-make for multiple
targets.  Two questions arise from this:

1) Is there a standard way of specifying targets?  When I tried it on our
server the config files variously talked about x86_64-pc-linux-gnu,
x86_64-linux-gnu, x86_64-unknown-linux-gnu...

What is the standard specification for our three development targets and
where is it specified?  For instance, would this be correct for an initial
install?

 ./configure --disable-flattened --enable-multi-platform --target=
x86_64-linux-gnu
 make install

...and for the following installs?

 ./configure --disable-flattened --enable-multi-platform --target=
i386-linux-gnu
 make install

 ./configure --disable-flattened --enable-multi-platform --target=
i386-mingw32
 make install

[Regarding the last target, we have another issue that is nothing to do with
GNUstep i.e. The standard mingw32 tools on Ubuntu don't support Objective-C
:o{  Shouldn't be too hard to add it though (hopefully).]

This process appears to set up relevant directories within /usr/lib/GNUstep/

2) Does 'multi-target' actually work reliably & transparently in practice or
is it an aspiration?  It is certainly an excellent idea.  Also, what is the
correct syntax?

 make static=yes shared=no --target=x86_64-linux-gnu

If it's not yet production quality then maybe it would be feasible to adapt
the pmake scripts that we use at the moment to take over the work of
gnustep-make.  I am assuming that it would just need some header and library
paths and include/link directives - maybe also some macro definitions.  Are
these requirements documented anywhere?


***************************************************************************
2) Distributing tools without headaches - packaging everything as
statically-linked applications without the need for GNUstep directory
structure/shared libs/GNUstep.sh
***************************************************************************

The second big issue - and one that many people have asked about over the
years.  We simply want to send Tools out as completely self-contained
applications that people can run from the command line on linux and win32 as
if they were statically-linked C or C++ applications without any need for
install scripts, extra directories, dynamic libraries/DLLs, sourcing shell
scripts or changes to their startup sequence.  It doesn't matter if the
Tools are bigger than ideal.

PLEASE DON'T REPLY "why would you want to do that?" as has happened in the
past - we just DO and so do many other people who have asked about exactly
the same thing because their users don't want to have to mess about with
system admin just to use some applications.

There seem to be (at least) three issues here:

1) Building libraries and tools with static linkage.
This is meant to be as easy as:

 make static=yes shared=no

But when we have tried that it doesn't always seem to work.

As a matter of fact, just trying to build gnustep-base (1.12.0) on the
native target fails at the moment:

 ./configure --target=x86_64-linux-gnu
 make
[snip]
 Compiling file NSDistributedLock.m ...
 make[2]: *** No rule to make target
`shared_obj/NSDistributedNotificationCenter.o', needed by
`shared_obj/libgnustep-base.so.1.12.0'.  Stop.
 make[1]: *** [libgnustep-base.all.library.variables] Error 2
 make[1]: Leaving directory
`/home/mwh/Coding/Obj-C/Foundation-stuff/gnustep-base-1.12.0/Source'
 make: *** [internal-all] Error 2

Any thoughts on this would be appreciated.

2) Avoiding the GNUstep directory structure and the loading of shared
libs/resources.

Because we are not using any graphical resources (Foundation only) I am
hoping that this is less difficult than some have implied.  However, there
does always seem to be some talk about loading shared libraries and it is
not clear if this can be fundamentally avoided somehow.


3) The need for GNUstep runtime e.g. gdomap, gdnc, Obj-C runtime?

I am not sure what is required here and whether it is started automatically.
For instance, which NS* objects require gdomap or gdnc?  Do they start them
if they aren't running already?  Is the Objective-C runtime compiled into
the Tool automatically or does it depend on linkage options?  There may be
other issues of which we are not aware.

***************************************************************************


Some thorough documentation in one place on the GNUstep site that deals with
these issues in a step-by-step way would be very valuable in helping GNUstep
become more widely used.  If it already exists and we haven't seen it then
my apologies and please point us to it - but the HOW-TO's that we have seen
so far fall quite a way short of clear & authoritative instructions.

Many thanks for your time reading this.  We are looking forward to informed
responses that will help us to use Obj-C/GNUstep/Foundation for what we do -
feel free to CC messages direct to me

Michael



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

        _/    _/   _/_/_/             Hopkins Research Ltd
       _/    _/   _/    _/
      _/_/_/_/   _/_/_/          http://www.hopkins-research.com/
     _/    _/   _/   _/
    _/    _/   _/     _/               'touch the future'
                   
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]