Re: GSWeb crash upon startup [Was: Re: Eeeagh! I'm at my wits end.]

[Simon Stapleton]

On 28 Apr 2004, at 11:08, David Ayers wrote:
> > Scratch that.  it's spurious logging from gsweb.
>
> Exactly, this has nothing to do wrt GC of libobjc and the -base GC 
> macros.
>
> But it would sill be very interesting to know why tweaking with code 
> guarded by those macros makes a difference.  Do you have a "namespace" 
> issue with the macros or other macros that control the GC macros?

And, it seems, it has nothing to do with those macros either.  Gah.  
Just synchronicity.

I rebuilt everything from base up unsing my 'fixed' NSProcessInfo, 
debug and non-debug versions.  And, hey presto, the problem has 
re-occurred.  Now I'm getting paranoid.

And, yes, 'Hello' and 'DynamicElements' still work fine.

So, I start debugging.  I run my debug version of the app under gdb, 
and find that I have no debug symbols for gnustep-base.  'Odd' I think 
to myself, and quit the debugger.   A quick `ldd` of the application 
reveals that I have _two_ instances of gnustep-base being included.  
The debug version, and the non-debug version.  This might well explain 
the issue - there may well be 2 instances of the various variables, one 
in each library, and if we set them up in one instance, then try to 
access them from another...kerblooey!  Why, though?

So, I start digging some more.  Removing the dependency on gnustep-base 
from the app still gives the same problem.  OK, not there.  Down 
deeper.  The various component frameworks don't rely on gnustep-base at 
all.  At least not directly.  Down even deeper.  And there it is.  My 
EnterpriseObjects framework relies on both gnustep-base and 
gnustep_base_d.  If I build with debugging _off_, we only get one.  
Remove the direct dependency on gnustep-base, plus the outdated 
dependency on gnustep-gui (I was using NSImage in the database 
previously, now expunged).  Now all I'm relying on is gnustep-db2.  a 
non-debug build gives me a dependence on gnustep-base, as expected.  
Debug build gives me (only) a dependence on gnustep-base_d

But the application still has a reliance on both.  Why?

Now.  It occurs to me that the problem may be to do with use of 
Frameworks.  Where something is built and installed as a library, we 
get a libXXX.so and an libXXX_d.so if we do a standard and a debugging 
build.  But a framework is different.  If I build a framework, I get 
the framework.  A debug version built afterwards will 'blat' the 
existing one and leave a debug version.

I suspect the problem I'm seeing is due to the mixture of libraries and 
frameworks I'm using, as follows:

gnustep-base is a library
gnustep-db2 is a library
GSWeb, GSWExtensions, GSWExtensionsGSW are all frameworks.
My app has a bunch of frameworks.

Depending on my build order, (i.e. whether I build debug versions or 
not, and, if so, whether I build them first or last), various of the 
frameworks are relying on debug and non-debug versions of the 
libraries.

For example.  I have GSWeb built debug.  This gives me a dependency on 
gnustep-base_d
I build my app with no debug.  This, via gnustep-db2, gives me a 
dependency on gnustep_base
My app now loads 2 libraries, with ensuing hilarity.

So, the problem seems to be that building a Framework with debug 
replaces any existing non-debug version of the library.  This, combined 
with the number and complexity of the frameworks  in my app, causes 
runtime linking problems.

After some testing, I discover that if I build _all_ the frameworks 
with no debug, I can make the app work.  And if I build _all_ the 
frameworks with debug, after having built all the libraries with debug, 
it also works.
But any mixture of the two causes disaster.

So.  A question.  For framework XXX, why does framework.make not create 
the following files (for non-debug and debug respectively) in 
$(GNUSTEP)/Library/Frameworks

XXX
libXXX.so*
XXX_d
libXXX_d.so*

and symlinks to the libXXX* files in Library/Libraries?

Surely that would allow me to have cohabiting debug and non-debug 
versions?

Simon

--
AppleCare.  Now _there's_ an oxymoron for you.
--
PGP Key Id : 0x50D0698D