New release of the gnustep-base library � please test trunk

[Richard Frith-Macdonald]

I'd like to make a new release of gnustep-base in the near future.
We have a big patch needing merging in which will introduce binary incompatible 
changes, so this would probably be the last significant release in the 1.24 
series, and would be 1.24.5
The 1.24.5 release will provide quite a large number of minor bugfixes, 
particularly on 64 bit platforms.   This version includes checking of 
printf-style format string arguments when building using clang, and should be 
free of any faults detected by the clang static anlyser.
I'd like it to be a version we can confidently advise people to use, so please 
could people download and test base from svn trunk as much as possible during 
the next few days.

After this release, I'd like to go on to work on 1.25.0 with a focus more on 
supporting ObjC2 development since I now believe clang and the runtime are 
becoming / may have become sufficiently stable for us to be be able to produce 
a user-friendly install process for an ObjC2 development environment.

I think this will require some restructuring between gnustep-make and 
gnustep-base.  The reason for this is mostly that, while clang and David's 
objc2 runtime were both designed as drop-in replacements for gcc and the gnu 
runtime, the reality is that they aren't (certainly not when it comes to ObjC2).

1. I think, we need more library-combo's.  Specifically we should have a new 
runtime designation for David's objc2 runtime, rather than trying to treat it 
as a variation of the gnu runtime.
This would hugely reduce/simplify the required autoconf tests
2. I think we need library-combo specific compiler settings in gnustep-make.  
The original gnustrep-make design esentially assumed everything would be built 
using gcc.  However you can't get full ObjC2 support with gcc, and clang uses 
somewhat different flags, so we need different compiler flags and libraries to 
be used when building for ObjC2 than wehn  building ObjC1 code.
3. While giving clang first class support for libobjc2, I think we need to drop 
support for older versions (and possibly when compiling for ObjC1) to 
concentrate on targetting a specific minimum version (possibly 3.3  ... not 
sure what's actually needed).