new library combo gnugc-gnu-gnu

[Nicola Pero]

I cleaned up a little the GC support in gnustep-make.

I have basically introduced a new type of ObjC runtime library - 'gnugc',
which is the GNU runtime with GC compiled in.

We now have three types of ObjC runtime library - nx, gnu, gnugc.

'make gc=yes' is now automatically converted into 'make
OBJC_RUNTIME_LIB=gnugc', which causes a different library-combo,
gnugc-gnu-gnu (or gnugc-fd-nil) to be used.

I'd like now to have gcc patched to compile libobjc against the gcc's
boehm-gc library when the option --enable-objc-gc is passed to gcc.  I
thought we wanted also to always have gcc use --enable-objc-gc but I was
told that boehm-gc is much less portable than libobjc, so let's forget
about it :-)

But at least I'll try to have a recommendation to actually enable that
option written down somewhere in the gcc doc so that maybe we can convince
distributions (other than debian, which always rules and already ships by
default libobjc_gc as well as libobjc with gobjc) to ship both libobjc and
libobjc_gc by default on all systems where it's supported.

If GC libraries get more widely used, we could get at the point where on
many systems you have both non-GC and GC core libraries installed.  
Library combos do manage that cleanly, except you can only use one of the
two - GC or non-GC environment at a time (and we don't expect end-users to
know that there are library combos at all, or to switch environment just
to run a command).

We could work around this limitation - if we ever feel we need - by
appending _gc to all GC libraries (so they are not only in a different
directory, but also have a different name), and then it would be possible
a special setup in which you have both gnu-xxx-yyy and gnugc-xxx-yyy
libraries in the linker path (I mean ld.so.conf) [they no longer would
conflict because of the different name], and both gnu-xxx-yyy and
gnugc-xxx-yyy tools in the PATH (so it would automatically find
efficiently the gnu or gnugc tool if only one of the two exists).  
Library-combos would still be used when loading bundles etc.

I'd like to see how things go before making any change in this sense.

I think we would also need to update gnustep-objc to use the name
'libobjc_gc' rather than 'libobjc' when compiling with gc enabled.  This
is what gcc does (and it does it for a good reason, that it compiles both
libobjc and libobjc_gc and they must have different names) and I think we
want to have a standard naming to prevent confusions.  gnustep-make now
links -lobjc_gc -lgc for the gnugc library-combo, rather than -lobjc.

I am not very comfortable with the hardcoded -I/usr/include/gc in
core/base/base.make.in, and we might have to address that issue at some
point (maybe a -L might be required for -lgc as well).

Please let me know if you have any comments.

I think/hope the current setup should be enough to allow people (at least
hackers) to work on GC libraries quite comfortably.