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.

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.

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

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

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)

Finally this is merged

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

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?

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

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.

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?