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

[WIP] netbsd.compat: fix build with musl #41537

Merged
merged 1 commit into from Jun 17, 2018
Merged

Conversation

orivej
Copy link
Contributor

@orivej orivej commented Jun 6, 2018

I am trying to make this succeed:

nix-build --arg crossSystem '(import <nixpkgs/lib>).systems.examples.musl64' -A netbsd.compat

The first issue I encountered is that coreutils don't build for musl, but luckily they are only needed for the build platform. Here:

nativeBuildInputs = [ makeMinimal ];
makeFlags = [ "INSTALL=${coreutils}/bin/install" ];

I could have added coreutils to nativeBuildInputs and deleted makeFlags, but the definition seems to be making a point of using them only for install, so I have qualified them with buildPackages.

The next issue is that netbsd.compat configure fails to find zlib.h. From config.log:

configure:2220: checking for zlib.h
configure:2230: x86_64-unknown-linux-musl-gcc -E  conftest.c
configure:2227:10: fatal error: zlib.h: No such file or directory
 #include "confdefs.h"
          ^~~~~~~~
compilation terminated.
configure:2236: $? = 1
configure: failed program was:
#line 2226 "configure"
#include "confdefs.h"
#include <zlib.h>
configure:2255: result: no
configure:2260: error: zlib must be installed in a compiler-visible path

My test using the environment of the failed build:

$ echo '#include <zlib.h>' > test.c
$ x86_64-unknown-linux-musl-gcc -c test.c
test.c:1:10: fatal error: zlib.h: No such file or directory
 #include <zlib.h>
          ^~~~~~~~
compilation terminated.
$ env | grep zlib
NIX_TARGET_LDFLAGS= -L/nix/store/n1gw5s811sz37c8b9204nbmrpiqql2sr-zlib-1.2.11-x86_64-unknown-linux-musl-dev/lib -L/nix/store/64nyx4j4h1947vrvyn92ja3jchyq1g0b-zlib-1.2.11-x86_64-unknown-linux-musl/lib
NIX_TARGET_CFLAGS_COMPILE= -isystem /nix/store/n1gw5s811sz37c8b9204nbmrpiqql2sr-zlib-1.2.11-x86_64-unknown-linux-musl-dev/include
buildInputs=/nix/store/n1gw5s811sz37c8b9204nbmrpiqql2sr-zlib-1.2.11-x86_64-unknown-linux-musl-dev

So the issue is that x86_64-unknown-linux-musl-gcc is not using NIX_TARGET_CFLAGS_COMPILE, but I am not sure what exactly goes wrong.

@matthewbauer
Copy link
Member

matthewbauer commented Jun 6, 2018

I am trying to make this succeed:
nix-build --arg crossSystem '(import <nixpkgs/lib>).systems.examples.musl64' -A netbsd.compat

Is that the right way to use Musl?

@dtzWill had me testing with this:

nix-build --arg localSystem '{config="x86_64-unknown-linux-musl";}' -A netbsd.compat

Which hopefully still works.

Either way your changes look good. No need to build install for musl if it's already available in buildPackages.

@dtzWill
Copy link
Member

dtzWill commented Jun 6, 2018

crossSystem vs localSystem: "build musl-native or cross-compile to musl using glibc tools".

I'm shocked that coreutils isn't building--looks like something indeed is rather wrong with cross wrapper and indeed the compiler isn't finding anything it should (and used to!). Will look into this...

@dtzWill
Copy link
Member

dtzWill commented Jun 6, 2018

Works on staging, "phew". Looks like it's this: #41429

@Ericson2314
Copy link
Member

I broke cross on staging a few weeks ago. 645f03b fixes it on staging yesterday. Maybe we should get that to master sooner?

@Ericson2314
Copy link
Member

Haha @dtzWill beat me.

@dtzWill
Copy link
Member

dtzWill commented Jun 6, 2018

re:this PR, as-is I think the coreutils used might not run on the builder at all--consider cross-compiling to aarch64? I'm not sure best way to express these things re:strings, I think this should work though.

UPDATE: Yep, here's cross-compiling to aarch64: https://gist.github.com/dtzWill/6b5db001e14e714563a696ede76bfd62
(nix build -f . --arg crossSystem '(import <nixpkgs/lib>).systems.examples.aarch64-multiplatform' netbsd.compat)

@matthewbauer
Copy link
Member

I'm not sure best way to express these things re:strings, I think this should work though.

I think @orivej are the best way. AFAICT Nixpkgs splicing will rewrite "native" build inputs to buildPackages automatically. If you're referencing it outside of the inputs, buildPackages will accomplish the same thing for you.

@dtzWill
Copy link
Member

dtzWill commented Jun 6, 2018

On staging I'm getting this: https://gist.github.com/dtzWill/f3a12fc18d2c16a9616f1ceb448003bc

Which looks like we need to specify/provide a host-native compiler... depsBuildBuild = [ buildPackages.stdenv.cc ] ?

@matthewbauer
Copy link
Member

Yeah I am still a noob on cross compiling - but that looks like it might work.

@orivej orivej closed this Jun 6, 2018
@orivej orivej deleted the musl-netbsd branch June 6, 2018 21:48
@orivej orivej restored the musl-netbsd branch June 6, 2018 21:49
@orivej orivej reopened this Jun 6, 2018
@matthewbauer
Copy link
Member

Note that the zlib thing is an issue with dropbear as well:

https://hydra.nixos.org/build/75406713/nixlog/1

@dtzWill
Copy link
Member

dtzWill commented Jun 9, 2018

dropbear seems to work on staging for me, both local and cross. Is that perhaps an old job (without the fix mentioned earlier in this thread)?

@dtzWill
Copy link
Member

dtzWill commented Jun 10, 2018

@Ericson2314 hmm, yes this would be nice to fix on master. Can you look into that? Is it just picking that commit?

@matthewbauer
Copy link
Member

I think we'll have to wait for it to work through staging. It's a true mass rebuild - every single hash will change.

FWIW I think we need to add some cross-compilation tests to release.nix to prevent this from happening again. The channel should block on some cross compilation things that we know should work.

@matthewbauer matthewbauer merged commit 9aa1624 into NixOS:master Jun 17, 2018
@matthewbauer
Copy link
Member

Merging for now because this is a step in the right direction. More PRs on this stuff are definitely welcome though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants