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 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
