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

[Frank Rehwinkel]

On Fri, May 31, 2013 at 12:15 PM, David Chisnall <address@hidden> wrote:

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)

 

Well, I want to use ARC for my code but I understand that doesn't require the libraries be built with ARC.  So no -fobj-arc for gnustep libraries.

 

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.

Still a little confused on this one.  I though if arc was not used, then gc was needed, so that would mean compiling with -fobjc-gc, but you say it has been deprecated on OS X for some time.  Does this mean I should be building gnustep without -fobjc-gc too?  Then I'm back to my first problem.  What to do about the _weak macro being redefined?

>  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

This is a very cool command line. 

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

So no ARC, no GC.  And I'm back to my original problem.  The __weak macro is being redefined.  Is the problem that clang shouldn't be internally defining it if GC is not enabled?

Is it a warning I can safely ignore?

-Frank