Re: Cross-compiling & distributing Tools

[Fred Kiefer]

Hi Michael,

the one person to answer your mail is surely Nicola. I had my different
goes at cross compilation with GNUstep, but as I was trying even more
complicated stuff than you, I failed.

One problematic bit has been left out by your description. When running
configure the make system tries to find out settings for the target
system. When cross compiling this cannot be done by executing test code
to see if it works or fails. In that case it will either be necessary to
run the configure script on the target system and copy back the result,
or to run configure with a lot of manually set values.

I would expect this wont be a big problem for your build environment, as
the systems you are using are similar enough.

One word of caution is needed for propel familiar with cross
compilation. The terms build, host and target have different meanings in
the GNUstep make framework to what they are normally used in the cross
compilation world.

Sorry, I cannot help you with any of your questions. I remember that
when using static linking for GNUstep, you need to make sure to link in
all the libraries statically. At least the ones using the objc runtime.
But there are people out there with loads of experience in that area. We
just need to bring together that experience and write it down in some
document.

Cheers
Fred

Michael Hopkins schrieb:
> 
> 
> 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'
>                    
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> 
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
>