bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to compile gnustep-baseadd with apple-apple-apple


From: David Ayers
Subject: Re: Unable to compile gnustep-baseadd with apple-apple-apple
Date: Tue, 13 Jan 2004 00:20:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210

Adam Fedor wrote:

On Saturday, December 27, 2003, at 10:37 AM, St├ęphane Corth├ęsy wrote:

and make wants to compile SSL bundle whereas it shouldn't do it for apple-apple-apple.


This doesn't happen for me either, as long as I do

make base=no add=yes

Hmmm. actually this patch was supposed to make those the default options for OS X. I don't have it so I can't check what's going wrong.
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/config.mak.in.diff?r1=1.10&r2=1.11&sortby=date

Then here are some patches for sources:

I fixes these. Thanks.


Thanks, I was hoping to finally get around to looking at them tomorrow.


BTW, gsweb uses objc_thread_id() implemented in thr-pthread.m, but this file is not compiled when we compile only gnustepbase-add.

thr-pthread is for the gnu runtime on darwin. Perhaps we should just put this function in GSCategoies for MacOSX to use? Or is there (or should we add) an NSThread method that would work better?


I've just grep'ed through gsweb and it is used quite often. This should definiatly either be resloved by using existing NSThread API or augmenting it if needed. It seems to be used for two main purposes: 1. identifing the thread (we can easily replace those with [NSThread currentThread] 2. An NSRecursiveLock category that access the GNUstep-base @private mutex variable to test the currect thread against the internal state of the mutex. (GSWUtil.m)

We really should look into that later usage, as it is non-portable and shouldn't be necessary. I'll put that on my TODO list but can't make a commitment on when this can be resolved.

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]