Package darling

[matthewbauer]

Issue description

Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.

https://www.darlinghq.org/

[davidak]

We already have this part: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/filesystems/darling-dmg/default.nix

[clacke]

Just heard of Darling. I would be delighted if it could be used for running x86_64-darwin builds on NixOS!

[davidak]

It seem to be packaged by @matthewbauer, but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps.

Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/darwin/darling/default.nix

darlinghq/darling#537

@matthewbauer could you update the package to the commit the "stable" AUR package uses and add a version as described here:

nixpkgs/doc/coding-conventions.xml

Line 275 in 1ef7e40

<literal>"pkgname-unstable-2014-09-23"</literal>.

?

https://aur.archlinux.org/packages/darling/

Then we can close this issue.

[kira-bruneau]

It looks like the project has started using tagged versions: https://github.com/darlinghq/darling/releases/tag/v0.2019.8

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[lambdadog]

I'd still be very interested in seeing this added, especially with the hope of future cross-compilation support

[ShamrockLee]

This would even make it possible to package Mac binaries for Linux!

[andrewrk]

I'm interested in this so that I can test cross compiled binaries when running zig tests.

[stale]

I marked this as stale due to inactivity. → More info

[andrewrk]

Not stale!!

[ShamrockLee]

We already have this part: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/filesystems/darling-dmg/default.nix

darling-dmg is just part of darling. To be exact, it is included as a submodule in the source tree of darling.

The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs.

Build instructions in the Darling Docs:

https://docs.darlinghq.org/build-instructions.html

[stale]

I marked this as stale due to inactivity. → More info

[lambdadog]

I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.

[FedX-sudo]

I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error:

       > CMake Error at src/CoreAudio/CoreAudio/CMakeLists.txt:20 (add_framework):
       >   Unknown CMake command "add_framework".
       >
       >

From this cmake file:

add_framework(CoreAudio
	FAT
    CURRENT_VERSION
    VERSION "A"

    SOURCES
        ${coreaudio_sources}

    DEPENDENCIES
        system
        cxx
        CoreFoundation
        pulse
)

As far as I can tell, the add_framework command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...

[FedX-sudo]

Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...

[danwdart]

What would therefore be a derivation?

[Atemu]

What do you mean @danwdart? It's just a fetchFromGitHub with fetchSubmodules = true;.

[xieby1]

I tried to re-package the prebuilt deb from darling GitHub releases.
Here is the nix code

default.nix

let
  pkgs = import <nixpkgs> {};
in {darling-bin = pkgs.callPackage ./darling-bin.nix {};}

darling-bin.nix

{lib, stdenv, fetchurl, dpkg, fakeroot}:
let
  version = "11.5_alpharelease1";
  rpath = ":${stdenv.cc.cc.lib}/lib64";
  src = fetchurl {
    url = "https://github.com/darlinghq/darling/releases/download/v0.1.20220929_update_sources_11_5/darling_0.1.20220929.focal_amd64.deb";
    sha256 = "1jjk2rpqzy1qh5w44vxjsacws04sdaclmk923d1n1wymkgadkcl2";
  };
in
stdenv.mkDerivation {
  pname = "darling-bin";
  inherit version;
  inherit src;
  buildInputs = [ dpkg fakeroot ];
  dontUnpack = true;
  installPhase = ''
    mkdir -p $out
    fakeroot dpkg-deb -x $src $out
    mv $out/usr/* $out/
    rm -r $out/usr
  '';
  postFixup = ''
    for file in $(find $out -type f \( -perm /0111 -o -name \*.so\* \) ); do
      patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" "$file" || true
      patchelf --set-rpath ${rpath}:$out/lib/x86_64-linux-gnu $file || true
    done
  '';
}

Save these 2 snippets as default.nix and darling-bin.nix, then run nix-build.

With 2 problems:

1. darling needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly.
   I use fakeroot to ignore this problem.
2. darlingserver always fails. I am not a darling expert, have no idea.

[danwdart]

Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.

[ShamrockLee]

I tried to re-package the prebuilt deb from darling GitHub releases.

It could be named darling-bin when entering Nixpkgs.

[xieby1]

It could be named darling-bin when entering Nixpkgs.

Good suggestion.
I've edited those two scripts.

[danwdart]

I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my shell.nix to a buildFHSUserEnv version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.

[zhaofengli]

After a bit of tinkering I got Darling to build from source. I opened #227765 with more info. Please give it a try!

[ShamrockLee]

The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs.

It seems that they now use darling_server instead of the kernel module. This would make packaging easier.

https://docs.darlinghq.org/internals/basics/system-call-emulation.html?highlight=kernel%20module#introduction

[ShamrockLee]

It seem to be packaged by @matthewbauer, but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps.

@matthewbauer What's the purpose of darwing.darling? If it is only the sandbox part of Darling, a new name like darling-sandbox would bring less confusion.

Update: Opened PR #228113 to do the renaming.