Undefined symbols for architecture x86_64:
"_NSDefaultRunLoopMode", referenced from:
fl_open_display() in Fl_cocoa.o
fl_ready() in Fl_cocoa.o
fl_wait(double) in Fl_cocoa.o
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in Fl_cocoa.o
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in Fl_Sys_Menu_Bar.o
"_OBJC_CLASS_$_NSDate", referenced from:
objc-class-ref in Fl_cocoa.o
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in Fl_cocoa.o
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in Fl_Native_File_Chooser_MAC.o
ld: symbol(s) not found for architecture x86_64
Compiling Fl_cocoa.mm...
Fl_cocoa.mm:4079:30: error: use of undeclared identifier 'version'; did
you mean 'Fl::version'?
NSOperatingSystemVersion version = [[NSProcessInfo processInfo]
operatingSystemVersion];
^~~~~~~
Fl::version
../FL/Fl.H:262:17: note: 'Fl::version' declared here
static double version();
^
Fl_cocoa.mm:4079:5: error: use of undeclared identifier
'NSOperatingSystemVersion'
NSOperatingSystemVersion version = [[NSProcessInfo processInfo]
operatingSystemVersion];
^
Fl_cocoa.mm:4080:9: error: use of undeclared identifier 'version'
M = version.majorVersion;
^
Fl_cocoa.mm:4081:9: error: use of undeclared identifier 'version'
m = version.minorVersion;
^
Fl_cocoa.mm:4082:9: error: use of undeclared identifier 'version'
b = version.patchVersion;
^
5 errors generated.
I'm unsure about
- is it ok to apply this patch globally, or should it be overridden for tigervnc only?
- how many rebuilds it triggers
- whether it was neccessary to update to latest dev version (seems to work)
The bug report indicates that others distros just includes this patch (?)
Cf. #1498. vcunat: the patch should be usable globally, as e.g. Arch does it.
Using autoreconfHook doesn't work for me, maybe --force is bad for it.
applyAndFun has a bug resulting in the same arg beeing added more than
once when using a concatenating merge function for the attr set.
I've tried giving the function a name "overridableDelayableArgs" which
resembles its usage much more.
important refactoring:
applyAndFun had .fun and .funMerge only when passing the merge
function lib.mergeOrApply
composableDerivation {
initial = {
...
};
}
to
overridableDelayableArgs has always .replace and .merge
composableDerivation {} {
...
}
svn path=/nixpkgs/trunk/; revision=14428
