"John Wiegley" <jo...@newartisans.com> writes: >>>>>> Michael Sperber <sper...@deinprogramm.de> writes: > >> Also, maybe I misunderstood you - what do you mean by "reference"? It seems >> the reference is in gcc itself - the C file I'm compiling is trivial: > >> [nix-shell:~/]$ gcc ~/temp/x.c >> ld: file not found: /usr/lib/system/libsystem_coreservices.dylib for >> architecture x86_64 >> collect2: error: ld returned 1 exit status > >> [nix-shell:~/]$ which gcc >> /nix/store/65yrkjclp6g71j9x16vcglqdw62xbnx7-gcc-wrapper-4.8.3/bin/gcc > > By reference I mean the dynamic library reference in the gcc executable. I > would *think* that this would be solved by rebuilding gcc from sources: > > rm -fr /nix/store/65yrkjclp6g71j9x16vcglqdw62xbnx7-gcc-wrapper-4.8.3/ > nix-env --option build-use-substitutes false -i gcc-wrapper-4.8.3 > > The problem, if I'm guessing correctly, is that the Hydra build server is > referencing a dylib that doesn't exist for you on your system -- a problem > which has cropped up a few times in the past.
Nothing to do with Hydra, it turns out. Instead, Xcode - even though I'm running Mavericks - seems to think I'm running Yosemite: > xcrun -show-sdk-version 10.10 ... and the libraries that the get referenced indeed depend on libsystem_coreservices.dylib. I'm guessing the recent Xcode update somehow triggered this. The underlying cause I don't know (Apple really wants me to upgrade to Yosemite?), but I can work around it with: export SDKROOT=macosx10.9 Unfortunately, it seems --pure (and nix-env generally) then *unsets* that environment variable again. Any way I can make Nix have its stick around? -- Regards, Mike _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev