Crash at startup on `aarch64-darwin`
I am trying to update csharp-ls from 0.15.0 to 0.16.0 on nixpkgs (https://github.com/NixOS/nixpkgs/pull/367940).
The package builds ans runs fine on our other platforms: x86_64-linux, aarch64-linux and x86_64-darwin, but fails to run on aarch64-darwin:
glepage@darwin01 ~/nixpkgs (csharp-ls)> ./result/bin/csharp-ls
fish: Job 1, './result/bin/csharp-ls' terminated by signal SIGKILL (Forced quit)
0.15.0 works fine there.
Is there a way to replicate the issue on real hardware / no nix? Most of my development happens on macOS on aarch64 (Sequoia 15.2, M1 Pro) so I should be able to see it.
bob ~/bin $ dotnet tool install -g csharp-ls
You can invoke the tool using the following command: csharp-ls
Tool 'csharp-ls' (version '0.16.0') was successfully installed.
bob ~/bin $ csharp-ls --version
csharp-ls, 0.16.0.0
bob ~/bin $ uname -a
Darwin mbp.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:01:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6000 arm64
bob ~/bin $ whereis csharp-ls
csharp-ls: /Users/bob/.dotnet/tools/csharp-ls
bob ~/bin $ dotnet --version
8.0.404
I suspect runtime issue though, what is the version of dotnet runtime installed on the machine?
Yes, maybe it's because of some nix-related issue. Seems like we are using dotnet 8: https://github.com/NixOS/nixpkgs/blob/fa3448dfaaabec0ff2572274571afba87a89e639/pkgs/by-name/cs/csharp-ls/package.nix#L18-L19
I have just tried with sdk_9_0, but got the same issue.
This smells a whole lot like a codesigning issue, especially seeing as the macOS binaries are built from an Ubuntu runner. Here's a bit more context.
Adhoc signing should still be good enough, so fixing this is likely just a matter of building the aarch64-darwin binary from a macos-latest, macos-14 or macos-15 runner, so the dotnet build tool has access to the codesign binary.
Ok, this is weird as we are building on recent MacOS builders... Thank you for the information nonetheless :)
Ok, this is weird as we are building on recent MacOS builders... Thank you for the information nonetheless :)
I see buildDotnetGlobalTool is being used to build the nix package, which the docs say just repackages an existing NuGet package.
Since that NuGet package was presumably built and published by this repo's 'build' workflow, which exclusively uses ubuntu, its binaries likely aren't codesigned and I assume buildDotnetGlobalTool doesn't have any magic to fix that.
I see
buildDotnetGlobalToolis being used to build the nix package, which the docs say just repackages an existing NuGet package.Since that NuGet package was presumably built and published by this repo's 'build' workflow, which exclusively uses ubuntu, its binaries likely aren't codesigned and I assume
buildDotnetGlobalTooldoesn't have any magic to fix that.
This makes a lot of sense indeed.
Why wouldn't this problem occur on x86_64-darwin though ?
I see
buildDotnetGlobalToolis being used to build the nix package, which the docs say just repackages an existing NuGet package.Since that NuGet package was presumably built and published by this repo's 'build' workflow, which exclusively uses ubuntu, its binaries likely aren't codesigned and I assume
buildDotnetGlobalTooldoesn't have any magic to fix that.This makes a lot of sense indeed. Why wouldn't this problem occur on
x86_64-darwinthough ?
For whatever reason they made codesigning stricter on Apple Silicon, according to the article I linked earlier.
For whatever reason they made codesigning stricter on Apple Silicon, according to the article I linked earlier.
Understood, thanks !
Is there any news in this sector? My nvf (Nix-based neovim configurator) doesn't work on my Mac because of this 😭
@KennethHoff If the issue came from nuget re-packaging, you can write your own derivation to build csharp_ls from source as a nix package. You can refer how roslyn-ls did this.