This actually has no effect but it bugged me to keep seeing an old version
in the package names :) and since we're making a bunch of stdenv changes
at once, I might as well.
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
Darwin systems need to be able to find CoreFoundation headers as well as
libc headers. Somehow, gcc doesn't accept any "framework" parameters
that would normally be used to include CoreFoundation in this
situation.
HACK: Instead, this adds a derivation that combines the two. The result
works but probably not a good long term solution.
ALTERNATIVES: Maybe sending patches in to GCC to allow
"native-system-framework" configure flag to get this found.
It's a long build and generally painful to split into smaller commits,
so I apologize for lumping many changes into one commit but this is far
easier.
There are still several outdated parts of the darwin stdenv but these
changes should bring us closer to the goal.
Fixes#18461
Revert a revert of a merge that shouldn't have been in master but was intentionally in staging.
Next time I'll do this right after the revert instead of so far down the line...
This reverts commit 9adad8612b.
This currently only produces a static library, but is a start :) soon we
might be able to incorporate it into our stdenv, but we need to get the
build system to produce a proper .framework first.
We don't actually need the private headers and the private qos.h was
overwriting the public one, causing weird issues downstream (especially
with Swift's CoreFoundation)
I can't submit this in smaller units because the various components all
depend on one another during the stdenv bootstrap, so I think this is
the smallest sensible change I can make.
I also removed the symbol-hiding shenanigans in Libsystem. It might mess
up compatibility with 10.9 but I don't really want to support the added
complexity and I see little evidence of anyone else wanting to support
it. If someone cares, we might be able to revive compatibility, but for
now it'll stay like this.
The AVFoundation framework uses a relative path that presumes that
CoreGraphics is a child framework of ApplicationServices. It is not in
the 10.9 SDK.
This patch makes it one by tweaking the framework derivation generator
with special support to address this problem.
The `otool` binary is provided by the `cctools` package (and `binutils`)
on darwin, which is properly packaged and compiled from source.
This old standalone `otool` was simply a symlink to `/usr/bin/otool`,
which notably depended on the user having already installed the Command
Line Tools via XCode, and would fail dependent builds if they hadn't.
This also changes the versioning scheme to be in more "human-meaningful"
terms, so instead of the internal release numbers we talk about 10.10.5
or 10.9.5.
adv_cmds archive actually contains BSDmakefile, not BSDMakefile. While
that probably doesn't matter in default installations, it does matter
for case-sensitive filesystems.
`nix-env -qaP -A pkgs.darwin`
pkgs.darwin.libutil:
Commented-out because the package definition doesn't exist. The source
doesn't even provide a Makefile...
pkgs.darwin.objc4_pure:
Commented-out because the package is broken and referencing unknown
applefetchsource and libc_old names. It doesn't seem to be used by any
other packages too.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
This version just got released two days ago, while we were working for
cross-builds on 5.0.2. From the release notes it shouldn't introduce any
incompatibilities.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
GCC doesn't support attributes on enumerators, which could pose a
problem but fortunately not in this case. Here a
__attribute__((weak_import)) is used, which doesn't make much sense for
enumerators anyway (noone will die because the corresponding enumerator
won't be referenced either in older OS X versions).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
At the moment, this includes only dyldinfo, dwarfdump and dsymutil, but
we'll see whether we need more of these utilities later.
Tho reason those are wrapped in cctools-port is because it is the
binutils used to cross-compile for Mac OS X.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This provides a port of Mac OS X's CoreFoundation and is needed if we
want to be able to run dsymutil using maloader.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This toolchain contains Mach-O binaries and might not be useful in the
first place, but there are programs like dsymutil, where Apple didn't
release the source code, so we need a Mach-O loader...
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This basically is binutils for Mac OS X, but ported to work on
(GNU/)Linux and FreeBSD.
And it's up-to-date as well! I'm mentioning this, because it was quite
hard to find a recent port of it and I just accidentally stumbled on it
while trying to do the port by myself.
So thanks to @tpoechtrager for doing this.
Also, I've added two more patches, which essentially are:
* ld-rpath-nonfinal:
This allows -rpath to be used for linking non-final builds, which
was allowed for earlier versions of cctools and got a check for
that in more recent versions.
* ld-ignore-rpath-link:
Ignores the -rpath-link option, because the cross-wrapper uses it
in different places. Unfortunately, the cctools linker doesn't
support it, so we might need to implement this later if it's
possible (I'm not a Mach-O man^H^H^Hexpert).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This package provides the SDK and standard library needed for
cross-compiling to Mac US X. We're using xpwn here to extract the DMG.
Also, this version (XCode 5.0.2) only contains the SDKs for version 10.9
and 10.8, so we might need to add requireFile directives for older
versions as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Copy only the pc files related to X11 and OpenGL.
This should allow us to build our own version of libraries like
cairo without having the native ones be accidentally dynamically
linked in to things that depend on them.
Before this patch if we `dyldinfo -dylibs libpangocairo` we can
see that it was dynamically linked against the OS X (but seemingly
built against include files from the nix one, as we would get a
runtime complaint about missing symbols)
Setfile is included by other derivation, which in turns makes them unfree, too.
This causes plenty of evaluation errors on Hydra, i.e.:
at `haskellPackages_ghc763_profiling.wx.x86_64-darwin' [nixpkgs = ..., officialRelease = false]:
user-thrown exception: package ‘setfile’ has an unfree license, refusing to evaluate
Now, it's true that "setfile" is unfree, but this doesn't affect us: our
derivation doesn't include the actual binary -- it just contains a symlink to
"/usr/bin/SetFile". Arguably, our setfile derivation is free and we can
re-distribute it.
* Dropped "nolongdouble.patch". The patch no longer applies to Python 2.6, and
apparently isn't required anymore either.
* Added access to native Darwin arch utility. Python tries to run 'arch' in
the configure stage, but that binary reside in /usr/bin. To make it
available to the expression, the small wrapper darwinArchUtility is added as
a buildInput if appropriate.
* Don't pass --enable-shared. The build fails if we try to enable building of
shared libraries, apparently because some required libraries aren't linked,
i.e. the linker call isn't right.
TODO:
* Figure out how to enable shared linking.
* The resulting binary on Darwin seem to lack the binascii module.
svn path=/nixpkgs/trunk/; revision=17894
