Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build issues with nix on macOS Mojave #677

Open
tscholak opened this issue Nov 11, 2018 · 22 comments
Open

build issues with nix on macOS Mojave #677

tscholak opened this issue Nov 11, 2018 · 22 comments
Labels
build Building, testing, installing, packaging, etc

Comments

@tscholak
Copy link

tscholak commented Nov 11, 2018

I just cloned the repo and tried to build it with nix on macOS but to no avail:

$ git clone git@github.com:dhall-lang/dhall-haskell.git

$ cd dhall-haskell

$ git --no-pager log -1 --pretty=oneline
5db1051311c34c7709b3a11803e54ce4c911f272 (HEAD -> master, origin/master, origin/HEAD) Update stack/cabal config to sync with new structure (#671)

$ uname -a
Darwin futumorphism.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64

$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

$ echo $NIX_CFLAGS_COMPILE
-idirafter /usr/include

$ echo $NIX_CFLAGS_LINK
-L/usr/lib

$ nix-build
building '/nix/store/67p58mwal0lxmy16z77l6skh2p4w4z3k-cabal2nix-2.10.2.drv'...
setupCompilerEnvironmentPhase
Build with /nix/store/79qa9dkrjqh485pa888q0p2dfqznwdyp-ghc-8.4.3.
ignoring (possibly broken) abi-depends field for packages
ignoring (possibly broken) abi-depends field for packages
unpacking sources
unpacking source archive /nix/store/62hrfkr64piwp10q9pzxirvqk6n33v1f-cabal2nix-2.10.2.tar.gz
source root is cabal2nix-2.10.2
setting SOURCE_DATE_EPOCH to timestamp 1533552458 of file cabal2nix-2.10.2/test/golden-test-cases/zlib.nix.golden
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/private/var/folders/2y/4nx786m95275s94z8vpk5y_00000gn/T/nix-build-cabal2nix-2.10.2.drv-0/setup-package.conf.d -j8 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /private/var/folders/2y/4nx786m95275s94z8vpk5y_00000gn/T/nix-build-cabal2nix-2.10.2.drv-0/Main.o )
Linking Setup ...
clang-5.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]

In file included from /private/var/folders/2y/4nx786m95275s94z8vpk5y_00000gn/T/nix-build-cabal2nix-2.10.2.drv-0/ghc58514_0/ghc_4.c:1:0: error:


In file included from /nix/store/79qa9dkrjqh485pa888q0p2dfqznwdyp-ghc-8.4.3/lib/ghc-8.4.3/include/Rts.h:29:0: error:


/nix/store/79qa9dkrjqh485pa888q0p2dfqznwdyp-ghc-8.4.3/lib/ghc-8.4.3/include/Stg.h:77:10: error:
     fatal error: 'math.h' file not found
   |
77 | #include <math.h>
   |          ^
#include <math.h>
         ^~~~~~~~
1 error generated.
`cc' failed in phase `C Compiler'. (Exit code: 1)
builder for '/nix/store/67p58mwal0lxmy16z77l6skh2p4w4z3k-cabal2nix-2.10.2.drv' failed with exit code 1
cannot build derivation '/nix/store/cjy2rkd5qdqzpkqkgrdgl92vn3qlmyfh-cabal2nix-dhall.drv': 1 dependencies couldn't be built
error: build of '/nix/store/cjy2rkd5qdqzpkqkgrdgl92vn3qlmyfh-cabal2nix-dhall.drv' failed
(use '--show-trace' to show detailed location information)

Is there a workaround for this other than https://hydra.nixos.org/build/83911384/download/1/nixpkgs/manual.html#builds-on-darwin-fail-with-math.h-not-found? It doesn't seem that this workaround actually works...

@tscholak tscholak changed the title build issues on macOS build issues with nix on macOS Nov 11, 2018
@tscholak
Copy link
Author

I just noticed that math.h isn't in /usr/include but in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/. Hence I set $NIX_CFLAGS_COMPILE to that value instead. Unfortunately, that doesn't seem to do the trick either :/

@Gabriella439
Copy link
Collaborator

@tscholak: I probably won't be of much help here. The best I can do is to document the development environment I use for OS X which is working for me when doing development on Dhall projects:

  • I use OS X version 10.13 (High Sierra)
  • I have never installed the XCode developer tools
  • I have never installed GHC (I use the one provided by nix-shell for each project)
  • My OS X computer doesn't have a /usr/include directory
  • My OS X computer doesn't have a /Library/Developer/ directory

@Gabriella439
Copy link
Collaborator

Some other things I should probably also mention:

  • I use a multi-user Nix installation on OS X
  • I haven't applied any work-arounds like modifying NIX_CFLAGS_COMPILE or NIX_CFLAGS_LINK

@tscholak
Copy link
Author

thank you @Gabriel439!
I have tried to reproduce the error with a single-user installation of nix on a High Sierra machine (17.7.0), but I can't. It could be something about Mojave, or maybe this particular installation of nix is somehow broken...

@Gabriella439
Copy link
Collaborator

@tscholak: Could the issue be that you installed the XCode developer tools? Has anybody tested if uninstalling them fixes the problem?

Also, do you have ghc installed? Some comments on that issue seemed to indicate that this might be due to interference from a globally installed ghc

@tscholak
Copy link
Author

both machines (darwin 17.7.0 and 18.0.0) have a global ghc:

$ ls -lah `which ghc`
lrwxr-xr-x  1 root  wheel    67B 26 May 12:49 /usr/local/bin/ghc -> /Library/Frameworks/GHC.framework/Versions/8.0.2-x86_64/usr/bin/ghc

and both machines have the xcode dev tools installed. the only difference I could find so far is the macOS version

@tscholak
Copy link
Author

tscholak commented Nov 11, 2018

ok, let's try this again... I've upgraded to multiuser nix on Mojave:

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 18.2.0, macOS 10.14.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.1.3`
 - channels(root): `"nixpkgs-19.03pre158005.32340793aaf"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

stay tuned...

encountered so far:

@Gabriella439
Copy link
Collaborator

Yeah, I'm familiar with NixOS/nix#2244. That will be trickier to fix because I'm depending on a specific revision of nixpkgs for support for static linking of binaries (See: NixOS/nixpkgs#43795)

It sounds like this is a Mojave-specific issue, then

@tscholak tscholak changed the title build issues with nix on macOS build issues with nix on macOS Nov 12, 2018
@tscholak tscholak changed the title build issues with nix on macOS build issues with nix on macOS Mojave Nov 12, 2018
@joneshf
Copy link
Collaborator

joneshf commented Jan 25, 2019

Do we know which versions of dhall this affects? We're looking to lock down dhall versions across High Sierra, Mojave, and Linux (using the pre-compiled binaries on Linux).

We were on 1.15.1, but we can't find the linux binaries anymore so we've gotta upgrade to something newer. 1.15.1 seems to still build on Mojave though. We tried 1.19.1, but on Mojave it gives the failures explained in this issue.

@Gabriella439
Copy link
Collaborator

@joneshf: My understanding is that this only affects things built by Dhall's CI since it uses a very specific version of Nixpkgs to build static executables. Building with cabal/stack/brew should still work on all platforms

If you want to fix Dhall's CI to build it for you then you will need to forward port the static Haskell executables work to work against newer versions of Nixpkgs/Cabal. Specifically, you would need to forward port these two forks of Nixpkgs and Cabal to rebase those sets of changes onto newer versions:

cabal_patched_src = pkgsNew.fetchFromGitHub {
owner = "nh2";
repo = "cabal";
rev = "748f07b50724f2618798d200894f387020afc300";
sha256 = "1k559m291f6spip50rly5z9rbxhfgzxvaz64cx4jqpxgfhbh2gfs";
};

nixpkgsStaticLinux = fetchNixpkgs {
owner = "nh2";
rev = "925aac04f4ca58aceb83beef18cb7dae0715421b";
sha256 = "0zkvqzzyf5c742zcl1sqc8009dr6fr1fblz53v8gfl63hzqwj0x4";
outputSha256 = "1zr8lscjl2a5cz61f0ibyx55a94v8yyp6sjzjl2gkqjrjbg99abx";
};

Alternatively, you could politely nudge people to merge the necessary changes to complete the static executables work:

NixOS/nixpkgs#43795

@joneshf
Copy link
Collaborator

joneshf commented Jan 25, 2019

Oops, sorry for being confusing. Let me provide more information.

N.B. Before reading further: we're not really looking for a fix to our situation. We're fine with any version of Dhall (we've been using 1.15.1 for a while now, but that's mostly out of laziness). So don't feel like you have to go out of your way to diagnose or help or anything like that. If you have a fix, great! We'll gladly take help, but it's not expected nor being asked.

We use nix on High Sierra and Mojave. When we tried to build 1.19.1 we did something like this:

let
  dhall = import dhallTarball;

  dhallTarball = builtins.fetchTarball {
    sha256 = "0fwz1kz9d0ny4209cxwj1zl7hqglxphyfvpf9mcy8c11b9zhdgdv";
    url = "https://github.com/dhall-lang/dhall-haskell/archive/1.19.1.tar.gz";
  };

  nixpkgs = import nixpkgsTarball;

  nixpkgsTarball = builtins.fetchTarball {
    sha256 = "1ib96has10v5nr6bzf7v8kw7yzww8zanxgw2qi1ll1sbv6kj6zpd";
    url = "https://github.com/NixOS/nixpkgs/archive/6a3f5bcb061e1822f50e299f5616a0731636e4e7.tar.gz";
  };
in
  nixpkgs.mkShell {
    buildInputs = [ dhall.dhall ];
  }

That worked on High Sierra, but failed on Mojave. I have High Sierra, co-worker has Mojave, so I can't validate the failures. But, they mentioned that this issue is what they run into.

We can build dhall fine on either High Sierra or Mojave with something like:

let
  nixpkgs = import nixpkgsTarball;

  nixpkgsTarball = builtins.fetchTarball {
    sha256 = "1ib96has10v5nr6bzf7v8kw7yzww8zanxgw2qi1ll1sbv6kj6zpd";
    url = "https://github.com/NixOS/nixpkgs/archive/6a3f5bcb061e1822f50e299f5616a0731636e4e7.tar.gz";
  };
in
  nixpkgs.mkShell {
    buildInputs = [ nixpkgs.dhall ];
  }

This gives us 1.15.1. This has worked well for a long time.

Recently, we wanted to use dhall lint in CI. Our CI is Linux based. We can't run nix on our CI currently, and we don't want to build dhall on our CI machines. We can't find the dhall 1.15.1 static binaries anymore, so we have to use a version that has static binaries available. That leaves us with deciding between: 1.16.1, 1.17.0, 1.18.0, 1.19.0, 1.19.1 (which we know won't work), 1.20.0, and 1.20.1.

I was hoping to figure out which of these versions are affected by the issue laid out here so we could use one that will build on Mojave. If we don't know which versions are affected, that's fine. I figured it was worth asking in case the information was readily available.

@Gabriella439
Copy link
Collaborator

@joneshf: My guess is that this would probably affect all versions that were built using static linking. The reason why is that I believe this is likely an issue with Nixpkgs and Dhall hasn't changed the revision of Nixpkgs that it depends on since static linking was introduced.

@joneshf
Copy link
Collaborator

joneshf commented Jan 31, 2019

Ah. That makes sense! Thanks!

@Gabriella439
Copy link
Collaborator

You're welcome! 🙂

@sjakobi sjakobi added the build Building, testing, installing, packaging, etc label Nov 12, 2019
@ari-becker
Copy link

I have a teammate who got bit by this, on both 1.30.0 and 1.31.0.

Yeah, I'm familiar with NixOS/nix#2244. That will be trickier to fix because I'm depending on a specific revision of nixpkgs for support for static linking of binaries (See: NixOS/nixpkgs#43795)

It sounds like this is a Mojave-specific issue, then

@Gabriel439 I see that in the interim, static-haskell-nix is now based on nixpkgs unstable again?
NixOS/nixpkgs#43795 (comment)

If so, would it be possible to update the nixpkgs pin and release a 1.31.1?

@Gabriella439
Copy link
Collaborator

@ari-becker: I tried to update a couple of months ago and ran into this issue: nh2/static-haskell-nix#73

... but I can try again and see if anything changed since then

@Gabriella439
Copy link
Collaborator

@ari-becker: Yeah, I updated to the latest static-haskell-nix and got the same result as nh2/static-haskell-nix#73 (comment)

@ari-becker
Copy link

@Gabriel439 I see, thanks for trying again.

I guess that my current workaround is to use https://github.com/justinwoo/easy-dhall-nix considering that my use-case only requires the final binaries. I'm not sure why the Darwin binaries aren't being fetched from cache (I verified with my teammate that he does have both the dhall-lang.org and the Cachix caches set up in his nix.conf), but well, it's rather difficult to debug these issues when I'm not running Darwin, everybody's working from home, and my teammate isn't yet sold on using Nix everywhere to begin with 😅

@Gabriella439
Copy link
Collaborator

@ari-becker: Note that none of the caches contain pre-built Darwin build products. They are currently Linux only

@ari-becker
Copy link

@Gabriel439 ah, I was under the impression that you were putting the OS X binaries in Cachix, at least? #1666 (comment)

@Gabriella439
Copy link
Collaborator

@ari-becker: Whoops! I forgot about that 🙂

I just uploaded the OS X binaries for 1.31.1 and I'm working on building and uploading them for 1.31.0, too

@Gabriella439
Copy link
Collaborator

Alright, 1.30.0 should be in the cache now

Part of the reason I forgot about these is that I run the release script from a Linux machine, so I have to remember to separately build and upload OS X build products

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Building, testing, installing, packaging, etc
Projects
None yet
Development

No branches or pull requests

5 participants