seems I've got a good sense for tracking weird problems currently. I've spotted an incompatibility (or, better said, difference) between GNU and NeXT runtimes regarding the handling of +(void)initialize in subclasses.
I've setup - as usual - a small testcase (PB.project for OS X, you'll need ProjectBuilderWO for that) for the problem at:
For those having no access to a machine with a NeXT runtime, the results are as follows.
NeXT runtime (Mach, Solaris, Win32):
znek@nerd:(~/Projects/unchecked/znek/InitializeTest)$ ./InitializeTest
Jul 18 16:24:46 InitializeTest[17312] +initialize A
Jul 18 16:24:46 InitializeTest[17312] string: is A
Jul 18 16:24:46 InitializeTest[17312] +initialize A
Jul 18 16:24:46 InitializeTest[17312] string: is B
GNUstep (FreeBSD):
znek@muller:(~/Projects/unchecked/znek/InitializeTest)$ ./obj/test
2002-07-18 16:43:53.507 test[67535] +initialize A
2002-07-18 16:43:53.513 test[67535] string: is A
I'm currently experiencing a problem in the EDMLParser because of this incompatibility, but there are workarounds for my problem. However I thought to let you know, in case someone else experiences similar problems.
Cheers,
Marcus
P.S.: I don't think that this is a bug in the GNU runtime, it's rather a bug in the NeXT runtime. In a discussion we just had on this topic, Erik, Helge and me favour the handling of the GNU runtime as it's much more intuitive and obvious.
--
Marcus Mueller . . . crack-admin/coder ;-)
Mulle kybernetiK . http://www.mulle-kybernetik.com
Current projects: finger znek@mulle-kybernetik.com