92188d9d17 broke the case where the user
has Xcode but not the command-line tools. So this commit restores
using xcrun to get the path to the SDK (falling back to / for the
non-Xcode case).
http://hydra.nixos.org/build/19953295
This makes stuff build with Xcode 6.1 on Mac OS X 10.9 (where we got
errors like "ld: file not found:
/usr/lib/system/libsystem_coreservices.dylib for architecture x86_64" due to the use of the 10.10 SDK).
In 3.3, a C++ class defined in a header will get a typeinfo symbol
like this (e.g. in Nix's src/libutil/util.o):
(__DATA,__datacoal_nt) weak external typeinfo for nix::BaseError
But in 3.4, this has changed to:
(__DATA,__datacoal_nt) weak external automatically hidden typeinfo for nix::BaseError
This causes the linker to change the symbol to:
(__DATA,__data) non-external (was signed char private external) typeinfo for nix::BaseError
i.e. losing its weak linkage. But without weak linkage, dynamic_cast
and other RTTI-based mechanisms (such as catching an exception of a
certain type) don't work across shared libraries / executables.
The clang compiler in the SDK doesn't have this behaviour, but it's
not clear exactly which version it is (it just says "based on LLVM
3.4svn").
Copying /usr/lib/system/libunwind.dylib at evaluation time doesn't
work (e.g. on Hydra). And copying binary system libraries is a bad
idea anyway for license reasons.
stack traces impossible.
* When stripping all symbols on Darwin, don't use the "-s" flag
since it has a completely different meaning (it takes an argument
specifying a file containing a list of symbols).
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10809
("/usr/bin/ld: can't use -s with -r (resulting file would not be
relocatable)").
* Since stdenv/generic had to be modified for this, I forked it in
situ. This should be merged later.
svn path=/nixpkgs/trunk/; revision=1121
