Re: soname of gc variant of gnustep-base

[Nicola Pero]

I think gnustep-make doesn't really have a satisfactory / consistent
support for garbage collection libraries ... I'd certainly like to fix
this.

It's not even actually clear how it is to be done :-)

I see two main incompatible ways we could implement it -

 1. - the GNU objc runtime with garbage collecting enabled is considered a
different runtime.  Then, instead of the gnu-gnu-gnu library-combo (for
example) the gnugc-gnu-gnu library-combo would be used.  All gc libraries
are installed into this different library-combo.

 2. - all garbage collecting libraries have _gc appended to their name (as
James suggested), but they still belong to gnu-gnu-gnu.

In gnustep-make the historical code seems contradictory ... there is code
which uses the library-combo gnu-gnu-gnu-gc, code which uses
gnugc-gnu-gnu, code which treats gc=yes as a variant similar to debug=yes
...  we need to choose one and implement that consistently and completely.

Basically, while I'd like best Solution 2., I think Solution 2. is much
more difficult to make to work.

Imagine that you have an application running without garbage collecting.  
Then, you have bundles for that application.  The application loads those
bundles at run-time - say it loads all bundles in a certain directory.  
Unfortunately, one of the bundle was compiled with garbage collecting
enabled.  When the application loads that bundle, it will get into
troubles (memory leaks I suppose ?).

How do we prevent an application from loading a bundle compiled with a
different memory management scheme ?  Or - how do we allow the same bundle
compiled with different memory management schemes to exist together ?

The library-combo is the traditional solution to this problem.

Because code compiled with libobjc and code compiled with libobjc_gc
should never mix, the standard solution would be to create a new
library-combo gnugc-gnu-gnu as opposed to gnu-gnu-gnu.

Then, all the system would normally be either using garbage collecting, or
not using it.  To run a tool/application with a different garbage
collecting scheme, you should be able to do

opentool defaults read --library-combo=gnugc-gnu-gnu
openapp GSTest.app --library-combo=gnugc-gnu-gnu

(NB: just read the source, I believe opentool is currently broken in this
respect - need to fix that).  This is great for developers, who can easily
switch between different memory managements and play with things etc -
it's maybe a pain for users.

This is more cumbersome than appending _gc to a garbage collecting
library, but the fact you can't mix garbage collecting libraries with
non-garbage collecting code really forces us to separate them more
strongly.

Maybe we could still implement Solution 2., by adding _gc to the object
files in bundles and frameworks as well ... and hacking our NSBundle
loading code to load the _gc object file if running with garbage
collecting enabled, and to load the non _gc object file if running without
it.

I suppose if we want to bring Solution 2., we need then to -

 - add _gc to all libraries compiled with gc;
 - add _gc to all bundles and frameworks object files compiled with gc;
 - link against _gc libraries if and only we are compiling with gc enabled;
 - modify NSBundle to load _gc bundle/framework objects files if running
with gc.

Solution 2. still means you can only have a tool/application compiled with
gc or without gc, but not both at the same time.  But you can be using an
application with gc and another one without at the same time easily.

Solution 1. does allow to have both of them for the same app at the same
time, but it's more cumbersome to use because it always requires a manual
switch to choose which one to use, and while power users can do it, for
normal users it's more difficult to run at the same time
tools/applications with gcs and tools/applications without it.

I've not yet made up my mind and would like to hear other (possibly
somewhat informed ... Helge ?) opinions.



> When the GC variant of the gnustep-base library is compiled, it has the 
> same soname as the non-gc variant. This is certainly not a good idea, as 
> then the dynamic linker will get them confused. There is currently no 
> way to have both GC and non-GC libraries in the default linker path at 
> the same time, which means any program that wants to use the GC variant 
> *must* be run with LD_LIBRARY_PATH set.
> 
> I'd suggest something like the following, which makes the soname 
> libgnustep-base_gc.so.1 instead of just libgnustep-base.so.1. I'm not 
> too well versed in the GNUStep makefile system (I've so far managed to 
> avoid using it), so I dunno if this is the best solution, but it worked 
> for me.
> 
> *** base.make.orig      Thu May  9 20:08:27 2002
> --- base.make   Thu May  9 20:08:45 2002
> ***************
> *** 48,51 ****
> --- 48,52 ----
>        AUXILIARY_CPPFLAGS += -DGS_WITH_GC=1
>        AUXILIARY_INCLUDE_DIRS += -I/usr/include/gc
> +     LIBRARY_NAME_SUFFIX := gc$(LIBRARY_NAME_SUFFIX)
>      endif
>    endif