no thread-safe +initialize in old gnustep runtime?

[Sebastian Reitenbach]

Hi,

since I experienced some strange behaviour with Burn on OpenBSD, when the 
application starts to get multi-threaded, I installed the old gnustep runtime, 
since with the new libobjc2 runtime I get those random crashers....
I thought the old runtime should be fine enough, since I got those message when 
the program got multi-threaded:

WARNING your program is becoming multi-threaded, but you are using an 
ObjectiveC runtime library which does not have a thread-safe implementation of 
the +initialize me
thod.  This means that any classes not already used may be incorrectly 
initialised, potentially causing strange behaviors and crashes.\nTo put this 
into context, the runtime bug has been knoown
 for several years and only rarely causes problems ... the easy workaround 
being to ensure that any classes used by a new thread have already been used in 
the main thread before the new thread
starts.\nIf you are worried, please build/run GNUstep with a runtime which 
supports the +initialize method. The GNUstep stable runtime (libobjc) and 
experimental runtime (libobjc2), available f
rom the GNUstep website and subversion repository, should both work.\nTo 
disable this warning (eg. for an application which does not suffer any problems 
caused by this runtime bug), please set
the GSSilenceInitializeWarning user default to YES.

However, after installing libobjc-1.6.1, and recompiling gnustep-base, I found 
that the above warning still shows up. Taking a look in the config.log I found 
those lines which I think are the relevant lines:


from config.log
configure:7098: checking for thread-safe +initialize in runtime
configure:7110: cc -o conftest -O2 -pipe -g  -I/usr/local/include 
-I/usr/local/include -I/usr/local/include -I/usr/local/include -fgnu-runtime -x 
objective-c  -L/usr/local/lib -L/usr/local/lib
-L/usr/local/lib -L/usr/local/lib conftest.c  -lpthread -lobjc   -pthread  >&5
In file included from ./config/config.initialize.m:4,
                 from conftest.c:98:
./config/objc-common.g:22: warning: cannot find interface declaration for 
'NXConstantString'
./config/objc-common.g: In function '+[NSObject new]':
./config/objc-common.g:44: warning: incompatible implicit declaration of 
built-in function 'calloc'
/usr/local/lib/libobjc.so.0.0: warning: strcpy() is almost always misused, 
please use strlcpy()
/usr/local/lib/libobjc.so.0.0: warning: sprintf() is often misused, please use 
snprintf()
configure:7110: $? = 0
configure:7110: ./conftest
class entered prematurely
configure:7110: $? = 1
configure: program exited with status 1
configure: failed program was:
...

So I wonder whether I need to do sth. additionally? I used gnustep-make 1.6.0 
and gnustep-base-1.22.0.

The actual problem I observed with Burn is that it starts an NSTask, it may or 
may not recognize whether it ended, i.e. for example when I try to create an 
ISO image:
        mkiTask = [[NSTask alloc] init];
        stdOut = [[NSPipe alloc] init];

        mkiArgs = [self makeParamsForVolumeId: volumeId
                                                                fileList: 
trackArray
                                 outFile: outFile
                          withParameters: parameters];

        [mkiTask setLaunchPath: mkisofs];
        [mkiTask setArguments: mkiArgs];
        [mkiTask setStandardError: stdOut];

        [self sendOutputString: [NSString stringWithFormat: _(@"Launching %@ 
%@"),
                                                                                
        mkisofs, [mkiArgs componentsJoinedByString: @" "]] raw: NO];

        [mkiTask launch];

        /*
         * Now we wait until the mkisofs task is over and process its output.
         */
        [self waitForEndOfTask];
NSLog(@"waited for the end of the task");
        /*
         * If mkisofs did not terminate gracefully we stop the whole affair.
         * We delete in any case the actual (not finished) file.
         */
        termStatus = [mkiTask terminationStatus];       // FreeBSD needs an 
lvalue for the WIF* macros


I may be lucky and I see the NSLog statement, but when I close Burn, and try 
again, it may not work. Burn has a console where I can see the output of 
external programs like mkisofs. In the console I can always see that the 
creation of the ISO worked well, since the output is shown in that console 
window.


Sebastian