On Fri, May 31, 2013 at 12:15 PM, David Chisnall < [email protected]> wrote:
> On 31 May 2013, at 16:24, Frank Rehwinkel <[email protected]> > 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
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
