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
