gnustep-dev
[Top][All Lists]
Advanced

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

Re: Should -base be built with -fobjc-gc


From: David Chisnall
Subject: Re: Should -base be built with -fobjc-gc
Date: Fri, 31 May 2013 17:15:24 +0100

On 31 May 2013, at 16:24, Frank Rehwinkel <address@hidden> wrote:

> -fnext-runtime isn't even an advertised option to the latest clang.

-fnext-runtime and -fgnu-runtime are deprecated in favour of -fobjc-runtime=

> I first started too optimistically trying to also pass -fobjc-arc and 
> -fblocks.  

You probably don't need -fblocks, as it should be implied on OS X, but no harm 
comes from passing it.  You shouldn't pass -fobjc-arc unless the code was 
written for ARC, which GNUstep isnt. 

> But what to pass to keep the compiler happy and stay true to the current 
> design of using gc?

Wait, did you want to use ARC or GC?  They're incompatible (on both OS X and 
GNUstep)
GC should work (although only if you built libobjc2 with BOEHM_GC=true), but is 
not very well tested and is deprecated on OS X for some time.

>  If I don't pass -fobjc-gc, I get warnings about the __weak macro being 
> redefined.  The original definition comes from <built-in>.  Does <built-in> 
> mean it comes from the clang compiler itself now and can I infer it didn't in 
> earlier versions or other compilers?  Should the code also be testing whether 
> there is already a definition for the symbols and why is the warning just 
> about the __weak macro and not the __strong macro?

Yes, built-in means it's predefined.

> The code in the header file:
> #if !__has_feature(objc_arc)
> #  if __OBJC_GC__
> #    define __strong __attribute__((objc_gc(strong)))
> #    define __weak __attribute__((objc_gc(weak)))
> #  else
> #    define __strong
> #    define __weak
> #  endif
> #endif
> 
> Should I just define the symbol __OBJC_GC__?  Symbols with that many leading 
> underscores are usually reserved for the system or the compiler.  When I run 
> clang with -fobjc-gc, I get the following link error:

Clang defines __OBJC_GC__ when compiling in gc mode:

$ echo | clang -x objective-c -E - -dM -fobjc-gc | grep OBJC_GC
#define __OBJC_GC__ 1

You should never define it yourself.

> ././config/objc-common.g:53:3: warning: assignment to Objective-C's isa is 
> deprecated in favor of object_setClass() [-Wdeprecated-objc-isa-usage]
>   obj->isa = self;
>   ^  ~~~~~~~
>   object_setClass( , )
> ././config/objc-common.g:46:5: note: instance variable is declared here
>  id isa;
>     ^
> 1 warning generated.

Add -Wno-deprecated-objc-isa-usage when compiling GNUstep?  Shows how long it's 
been since anyone tried compiling -base with gc support...

> Is _objc_assign_ivar supposed to come from the runtime library?  I

Yes.  It is defined in gc_boehm.c (the leading underscore is Darwin symbol 
mangling).

> s there another library that should be linked in in this case?  I didn't get 
> this error when -fobjc-gc was not used.

No, you wouldn't have done.

David




reply via email to

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