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? And assigning a derived class instance to a variable types as the base class is definitely legitimate/normal. 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. > 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. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
