gnustep-base on linux, irix, solaris and OSX

[Carl Eugen Hoyos]

I'm adapting a photorealistic rendering tool to perform distributed
rendering using Objective C Distant Objects, and since we have several
different types of computers here, I had to install gnustep-base on all
these machines. Here is what I found out about installing the base library
on the following systems: ix86-linux/Win32 (intel, amd, dual-PIII,
dual-athlon), powerpc-linux (G3), mips-irix6.5(O2, Indigo2 and Indy),
sparc-solaris2.7(Sun 4400 quadruple ultrasparc) and a G3 running OS X
10.1.4

I'm using the following classes of gnustep-base, so whenenver a target
seems to be stable to me, it means that these classes appear to work:
NSConnection, NSDate, NSDistantObject, NSHost, NSLock,
NSNotificationCenter, NSNumber, NSRunLoop, NSString, NSThread and their
superclasses

If you want to use NSConnection, you should install ffcall, because
although it is possible to call distant objects without it (passing
pointers to variables - bycopy in - instead of the variables themselves,
no return values), it's far easier to install ffcall than to produce
workarounds.
Of the four libraries that ffcall contains, gnustep-base only needs avcall
and callback, so I always only install those by using make
install-lib. That installs just the Header and Library files. If you also
use configure --includedir --libdir to install the libraries into the
gnustep-base tree, be careful though: The base library's configure script
expects the Header file to be in $GNUSTEP_SYSTEM_ROOT/Headers, but since
those headers differ from machine to machine, you want them to install in
$GNUSTEP_SYSTEM_ROOT/Headers/processor/os-type if you are using the same
directory structure for different computer types inside your NFS home
directory(as I used to until I found out that doesn't work if one wants to
use gcc2.95.x and gcc3.x alternatingly). So you have to copy them into the
right directory before running configure and don't forget to delete them
afterwards (make finds them in the subdirectory as well)!

It's possible to compile gnustep-base with gcc2.95.x, gcc3.0.x and
gcc3.1. However, not every compiler works for every target, and you should
know that compile time is FAR shorter using 2.95.x while the speed
improvement of the executable when using a newer compiler is difficult to
measure for our tool. On the other hand, using NSObject as root class
instead of Object only makes the code only about 1% slower, so this
shouldn't be a reason not to use the library.

If you use gcc2.95.x, don't forget to install gnustep-objc, as mentioned
in the INSTALL-HOWTO!

Threads work on every target I've seen, so if you need them, don't
hesitate to install a self-built compiler with enabled threads! These are
usually posix threads, so you have to link your executables with -lpthread
which seem to exist on most modern operating systems. To test it, use
diningPhilosophers located in the Testing subdirectory of the build
tree: Be careful, however: Programs intended to deadlock (like the hungry
thinkers) might even stop before producing any output - I recommend to
move the "Wait until we are hungry again" block to the begin of "while
(1)".

I'm using make1.2.1/base1.1.0 on every system except Windows, not only
because they claim to be "stable", but also because I produced good
results, so why change a working tool? However, gdomap1.1.0 doesn't work
on all targets, so you might want to download an experimental version of
the base library, run configure, change to the tools subdirectory and type
make gdomap to produce a running version. Don't forget that you have to be
root (superuser on win2k) to run it if you didn't change the port!

Since our rendering toot is normally built with static libraries only, I
prefer to use them - they also seem to be much easier to produce if you
compile the base library by hand. 

Machines:

ix86--SuSE--GNU-linux (stable)
gcc2.95.x, gcc3.0.x and gc3.1 should work, but since 2.95.x compiles so
much faster than the later ones, I recommed it if you don't need any of
the improvements introduced in version 3. To get threads you have to
configure the compiler whith --threads-enabled, that is NOT standard, but
will produce working posix-threads!
Install ffcall to use Distributed Ojects, and don't forget gnustep-objc if
you are using gcc2.95.x
Static and dynamic libraries available.

powerpc--SuSE-GNU-linux (stable)
gcc2.95.x, gcc3.0.x and gc3.1 should work, but since 2.95.x compiles so
much faster than the later ones, I recommed it if you don't need any of
the improvements introduced in version 3. To get threads you have to
configure the compiler whith --threads-enabled, that is NOT standard, but
will produce working posix-threads!
Install ffcall to use Distributed Ojects, and don't forget gnustep-objc if
you are using gcc2.95.x
Static and dynamic libraries available.

sparc--sun--solaris2.7 (stable)
The recommended compiler should be gcc3.0.4 because gcc3.1 doesn't compile
NSBundle.m of gnustep-base1.1.0. I think gcc provides posix threads on
this system even if not configured whith --enable-threads, but to use
them, you have to tell the gnumake configure script: The libraries you
have to link with are -lpthread -lrt (read man libposix4 for more
details). You have to call configure --with-thread-lib=-lpthread to avoid
using -lthread which doesn't work!
Install ffcall to use Distributed Ojects.
Static and dynamic libraries available.

mips--sgi--irix6.5 (surprisingly stable)
You can't compile the base library with gcc2.95.x, and 3.1 compiles more
of the Testing programs (nsarray) than 3.0.4 so 3.1 should be the
recommended compiler. To use threads, it's necessary to bootstrap a
compiler yourself: configure with --enable-threads=posix, that will work
as long as you link EVERY objective C executable with -lpthread, no matter
what warnings the irix linker produces!
Install ffcall to use Distributed Ojects.
Only static library.

ix86--pc--MSYS-mingw32 (do you know a stable Win32 program?)
Don't forget to read the README.MinGW which tells you how to install.
At the moment, there is only 2.95.3-5.
Install ffcall to use Distributed Objects. Passing structures as arguments
to distant objects doesn't work, you have to pass a pointer instead:
(whatever) function (bycopy in Struct * struct) works and isn't slowlier
than without the pointer (it was even faster when I tested it but I could
hardly believe that)
[NSConnection enableMultipleThreads] doesn't work correctly: I had to
protect my parallel calls of foreign functions of the same NSConnection by
using locks. However, that doesn't cost too much time and will hopefully
be unnecessary one day ...
Due to problems with mingw, it's impossible to include libtiff and libjpeg
Header files in the same file!
Only dynamic libraries, sad enough!

ix86--pc--cygwin (doesn't work!)
On this environment, it's possible to bootstrap the gcc3.x compilers
without problems (it even seems to be surprisingly fast compared to
similar linux computers), ffcall also seems to work, but the make process
of gnustep-base fails when making the library (shared) or already at the
beginning (static).

powerpc--apple--darwin5.4 (more or less stable)
Of course, you can follow the official instructions, produce a dynamic
library and compile the testing programs without any unexpected
warnings. But unfortunately, I wasn't able to produce any executable which
said something else then "Bus error" when running it.
So I found another solution using gnu-runtime instead of NeXT-runtime:
Download the gcc3.1 compiler and configure it with
--enable-threads=posix. Usually the installed compiler will produce object
files for the NeXT runtime if you don't say gcc -fgnu-runtime. To change
this behaviour, edit src-dir/gcc/config/darwin.h: You have to change the
word #define in line 73 to #undef. Then the runtime default is gnu. When
bootstrapping the compiler a nice working objective C gnu-runtime library
(which is a little bit faster than apples NeXT-runtime) will be compiled
and installed when make install. To use it, there is one (important) thing
left: After installing the compiler, you have to go (probably as root) to
install-dir/lib and produce the following dynamic link:
ln -s libobjc.a libobjc.dylib
This might seem senseless, but it forces the linker to use this library
instead of the NeXT-runtime!
The next (more difficult thing) to do is to compile ffcall if you want to
use Distributed Ojects: Download and untar it, configure it with CC=cc or
CC=gcc (both seem to work). Then change to avcall, rm
avcall-rs6000-sysv4.s, compile a new one with (g)cc avcall-rs6000.c -S -o
avcall-rs6000-sysv4.s, make, make install-lib and make tests. When running
tests, you already see which arguments may be passed (and returned) and
which won't work...
Then change to ../callback/trampoline_r, ln -s trampoline_r.h.in
trampoline_r.h, rm cache-rs6000-sysv4.s tramp-rs6000-sysv4.s, compile new
ones with (g)cc cache.c -S -o cache-rs6000-sysv4.s and (g)cc trampoline.c
-S -o tramp-rs6000-sysv4.s. Then change to ../vacall_r, rm
vacall-rs6000-sysv4.s, (g)cc vacall-rs6000.c -S -o vacall-rs6000-sysv4.s
-DREENTRANT.
Now you can make and make install-lib in callback. Don't run the tests,
they simply wont't work.
(That was the hard part.)
Now you have to edit gnustep-base-1.1.0/Source/NSDecimal.m: Move the line
#include <Foundation/NSDecimal.h> up so that NSDecimal.h is included
before any other files. Then you can configure and make shared=no the
library. To use threads, no libraries have to be included: -lpthread seems
to be part of standard c lib linking operation.
Nearly all Test files work, diningPhilosophers even works too good: If you
want to see something, you have to put the "Wait until we are hungry
again" - part to the beginning of the while(1) block.
gdomap doesn't work, you have to use the one in gnustep-base-1.3.2

Sorry for the long mail, Carl Eugen