FreeBSD packages: Init at 13.1

[Ericson2314]

Motivation for this change

Have working

nix-build -A pkgsCross.x86_64-freebsd.hello
nix-build -A pkgsCross.x86_64-freebsd.zlib
nix-build -A pkgsCross.x86_64-freebsd.zstd
nix-build -A pkgsCross.x86_64-freebsd.freebsd.sys

Running out of memory as NetBSD makeMinimal fails to build. Weird, know what's up @matthewbauer?

Oh netbsd make is cached, duh, this is freebsd libc itself.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

CC @wahjava

[Ericson2314]

I dropped link to this in https://forums.freebsd.org/threads/can-i-compile-a-freebsd-kernel-from-linux.64582/, a that is vaguely relevant.

[Ericson2314]

OK need to fix makefiles or bmake itself so non-default system rules -m propagate to recursive make---probably easiest thing to add an environment variable to bmake for this.

[sternenseemann]

IIRC Nix's configure script makes a point of stripping version information from system doubles, so it might be impossible to get such a double as builtins.currentSystem.

[Ericson2314]

You and @alyssais should work that out :) I am not sure what is more correct. If what we have is more correct, that is fine with me we can worry about native compilation later! :D

(i.e. systems that builtins.currentSystem would never produce are not a problem for cross compilation only,)

[kirillrdy]

Hi, firstly thank you for all the effort that was put into this MR !

unfortunately when i try

nix-build -A pkgsCross.x86_64-freebsd.hello

I get

building '/nix/store/ffa2r42x74j5mfsvkymj9s74w114kqyr-stdenv-linux.drv'...
remote: Enumerating objects: 91213, done.
remote: Counting objects: 100% (91213/91213), done.
remote: Compressing objects: 100% (78514/78514), done.
error: RPC failed; curl 56 OpenSSL SSL_read: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0
error: 5347 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
remote: Enumerating objects: 91213, done.
remote: Counting objects: 100% (91213/91213), done.
remote: Compressing objects: 100% (78514/78514), done.

can someone double check that this builds for others ? just so I know if there is something with my setup

[kirillrdy]

hi, actually i found the answer, something is broken with ssl on master, i've rebuild my nixos from previous well known configuration and now it seems to be building

[Mic92]

Is c++ known to work? I just tried cross-compiling patchelf in the patchelf repo and got this:

x86_64-unknown-freebsd13-ld: error: undefined symbol: _Unwind_Resume
>>> referenced by patchelf.cc:0
>>>               patchelf.o:(getElfType(std::__1::shared_ptr<std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > const&))
>>> referenced by patchelf.cc:0
>>>               patchelf.o:(error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&))
>>> referenced by new:0 (/nix/store/qbbik1n6qmmbwhc74fv9czm8qy21cmvf-libcxx-x86_64-unknown-freebsd13-12.0.1-dev/include/c++/v1/new:0)
>>>               patchelf.o:(resolveArgument(char const*))
>>> referenced 81 more times
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)

[9glenda]

Finally this is merged

[Ericson2314]

@Mic92 I built zstd and it worked so some C++ does, I thought.

[9glenda]

This pr just adds cross compilation support right? Or does it also add support for building the FreeBSD kernel on FreeBSD in case you get nix running there?

[Ericson2314]

@9glenda only cross compilation support, but I did cross compile the kernel too!

[Ericson2314]

My next stop would try to be NetBSD and FreeBSD in https://github.com/cleverca22/not-os. I think just using Nix on stock FreeBSD will actually be harder because modern FreeBSD once to mandate that all syscalls go through the same userland libc --- either we rebuild the entire userland with Nix, or we do impurities.

[Mic92]

It seems that with certain c++ features (i.e. c++17), you need libunwind linked as well.

This is what I added for patchelf to get it working:

  buildInputs = [ llvmPackages.libunwind ];
  NIX_LDFLAGS = "-lunwind";

Probably the macOS version already has something implemented?

[Ericson2314]

@Mic92 I guess changes like this are adding the problem? But it also didn't work without. Hmm.

[sternenseemann]

Yeah, this seems wrong as we are doing useLLVM

[Ericson2314]

Well forcing -lunwind is a sledgehammer I am skeptical enough, and it was causing failures even if its absense was also causing failures. I think it would be good to figure out why this was needed in the first place.