continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
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
