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

FreeBSD packages: Init at 13.1 #82131

Merged
merged 3 commits into from
Nov 14, 2022
Merged

Conversation

Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented Mar 9, 2020

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 Ericson2314 requested a review from nbp as a code owner March 9, 2020 06:17
@ofborg ofborg bot added 6.topic: fetch 2.status: merge conflict This PR has merge conflicts with the target branch labels Mar 9, 2020
lib/systems/examples.nix Outdated Show resolved Hide resolved
@Ericson2314
Copy link
Member Author

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
Copy link
Member Author

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.

@Ericson2314 Ericson2314 changed the title WIP: Free BSD cross compilation WIP: Add FreeBSD and fix NetBSD cross compilation Apr 20, 2020
@Ericson2314 Ericson2314 mentioned this pull request Apr 20, 2020
10 tasks
@ofborg ofborg bot requested review from peti and dtzWill August 7, 2020 18:12
@ryantm ryantm marked this pull request as draft October 23, 2020 03:02
@SuperSandro2000 SuperSandro2000 added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jan 18, 2021
# versions. That means that putting in the version as part of the
# config string is paramount.
freebsd12 = { execFormat = elf; families = { inherit bsd; }; name = "freebsd"; version = 12; };
freebsd13 = { execFormat = elf; families = { inherit bsd; }; name = "freebsd"; version = 13; };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@Ericson2314 Ericson2314 Nov 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,)

Ericson2314 and others added 3 commits November 4, 2022 16:49
The libc will be inferred.
A tricky thing about FreeBSD is that there is no stable ABI across
versions. That means that putting in the version as part of the config
string is paramount.

We have a parsed represenation that separates name versus version to
accomplish this. We include FreeBSD versions 12 and 13 to demonstrate
how it works.
Always set `SRCTOP`, set it with abs path

llvmPackages: Bump minimum version for FreeBSD

llvmPackages_*, libgcc, compiler_rt: Hack in enough libs that one can compiler C

freebsd.compat: Rename some things to work around cc-wrapper change

0bea4a1 / NixOS#191724 in particular
@rrbutani rrbutani mentioned this pull request Nov 7, 2022
92 tasks
@Ericson2314 Ericson2314 merged commit cd27a5b into NixOS:master Nov 14, 2022
@Ericson2314 Ericson2314 deleted the bsd-cross branch November 14, 2022 02:35
@kirillrdy
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Mic92 commented Nov 17, 2022

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
Copy link
Member

9glenda commented Nov 17, 2022

Finally this is merged

@Ericson2314
Copy link
Member Author

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

@9glenda
Copy link
Member

9glenda commented Nov 17, 2022

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
Copy link
Member Author

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

@Ericson2314
Copy link
Member Author

Ericson2314 commented Nov 17, 2022

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
Copy link
Member

Mic92 commented Nov 18, 2022

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?

@@ -156,7 +156,7 @@ let
echo "-B${targetLlvmLibraries.compiler-rt}/lib" >> $out/nix-support/cc-cflags
'' + lib.optionalString (!stdenv.targetPlatform.isWasm) ''
echo "--unwindlib=libunwind" >> $out/nix-support/cc-cflags
'' + lib.optionalString (!stdenv.targetPlatform.isWasm && stdenv.targetPlatform.useLLVM or false) ''
'' + lib.optionalString (!stdenv.targetPlatform.isWasm && !stdenv.targetPlatform.isFreeBSD && stdenv.targetPlatform.useLLVM or false) ''
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this seems wrong as we are doing useLLVM

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

ElvishJerricco pushed a commit to ElvishJerricco/nixpkgs that referenced this pull request Jan 8, 2023
github-actions bot pushed a commit that referenced this pull request Jan 28, 2023
K900 pushed a commit that referenced this pull request Jan 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: bsd Running or building packages on BSD 6.topic: exotic Exotic hardware or software platform 8.has: documentation 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10
Projects
None yet
Development

Successfully merging this pull request may close these issues.