On 21 Aug 2013, at 08:45, Richard Frith-Macdonald <[email protected]> wrote:
> > On 21 Aug 2013, at 08:19, David Chisnall <[email protected]> wrote: > >> On 21 Aug 2013, at 08:03, Richard Frith-Macdonald >> <[email protected]> wrote: >> >>> I haven't spoken up before because I have no particular knowledge of most >>> of what you mention, but I do know that the Performance framework builds >>> fine with the latest release (and with trunk) on several platforms. So if >>> it's not building for you then that must be with some specific unusual >>> setup. >> >> The errors I see are: >> >> Compiling file GSCache.m ... >> GSCache.m:503:1: warning: conflicting distributed object modifiers on return >> type in implementation of 'release' [-Wdistributed-object-modifiers] >> - (void) release >> ^ ~~~~ >> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:180:1: note: >> previous declaration is here >> - (oneway void) release NS_AUTOMATED_REFCOUNT_UNAVAILABLE; >> ^ ~~~~ >> GSCache.m:773:17: warning: incompatible pointer types assigning to 'NSLock *' >> from 'NSRecursiveLock *' [-Wincompatible-pointer-types] >> allCachesLock = [NSRecursiveLock new]; >> ^ ~~~~~~~~~~~~~~~~~~~~~ >> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:363:1: note: >> class method 'new' is assumed to return an instance of its receiver type >> ('NSRecursiveLock *') > > I'm not sure if the first two are compiler bugs? > As I recall the DO type qualifiers like oneway are required in the interface > but not in the implementation. Maybe that's a language change for objc2? No, it was just a gcc bug that it never propagated the type information down into the class. > And assigning a derived class instance to a variable types as the base class > is definitely legitimate/normal. While true, this is irrelevant. NSRecursiveLock is a direct subclass of NSObject, not of NSLock. You probably meant NSObject<NSLocking> as the type of the variable. > Anyway, I susppse we can twek things to make the compiler happy even if it's > a false alarm > >> + (id) new; >> ^ >> GSCache.m:857:32: warning: direct access to Objective-C's isa is deprecated >> in >> favor of object_getClass() [-Wdeprecated-objc-isa-usage] >> return class_getInstanceSize(isa); >> ^ >> /usr/local/GNUstep/System/Library/Headers/Foundation/NSObject.h:293:9: note: >> instance variable is declared here >> Class isa; >> ^ > > That's easy. Yes. >> GSCache.m:913:16: error: use of undeclared identifier 'content'; did you mean >> 'cgetent'? >> size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude]; >> ^~~~~~~ >> cgetent >> /usr/include/stdlib.h:262:6: note: 'cgetent' declared here >> int cgetent(char **, char **, const char *); >> ^ >> GSCache.m:913:16: warning: receiver type 'int (*)(char **, char **, const >> char >> *)' is not 'id' or interface pointer, consider casting it to 'id' >> [-Wreceiver-expr] >> size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude]; >> ^~~~~~~ >> GSCache.m:913:49: error: use of undeclared identifier 'headers' >> size += [content sizeInBytes: exclude] + [headers sizeInBytes: exclude]; >> ^ >> GSCache.m:926:16: error: use of undeclared identifier 'name' >> size += [name sizeInBytes: exclude] >> ^ >> GSCache.m:927:12: error: use of undeclared identifier 'value' >> + [value sizeInBytes: exclude] >> ^ >> GSCache.m:928:12: error: use of undeclared identifier 'objects' >> + [objects sizeInBytes: exclude] >> ^ >> GSCache.m:929:12: error: use of undeclared identifier 'params' >> + [params sizeInBytes: exclude]; >> ^ >> 4 warnings and 6 errors generated. >> >> They appear to be because it is directly accessing ivars that are not public >> and not exposed from a category on GSMimeDocument (in the first instance, >> I've not checked the subsequent ones). If these ivars are expected to be >> used outside of the GNUstep Base Framework, then they should not be hidden. >> If they are not expected to be used outside of the GNUstep Base Framework, >> then the Performance framework has a bug that only shows up with the >> non-fragile ABI. >> >> It fails after the first file, so I've not see what subsequent errors >> appear. > > Yes, the main part of this seems to be use of @defs which is no longer > supported with the non-fragile ABI (for obvious reasons). I guess this must > never have worked for non-fragile setups. > So why does it build for me on my clang-3.3 based system? Guess I need to > look at what compiler flags are being passed. I don't think it's using @defs. It's trying to directly access an ivar, which is not exposed in the header except with the fragile or mixed ABI (and should be @private in those, but isn't). David -- This email complies with ISO 3103 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
