julia_10-bin, julia_16-bin: add x86_64-darwin support #123394
Comments
|
On Mon 17 May 2021, Samuel Ainsworth wrote:
Now that #123188 has landed, we have derivations for binary releases of julia versions 1.0.x and 1.6.x on x86_64-linux. It would be nice to expand platform support for these derivations, esp. for x86_64-darwin since that's what I have access to and use frequently.
I've taken a hacky first stab at this already: https://gist.github.com/samuela/257b66127bceffcc11453a6992a92d3d. Unfortunately, it gets hung up on test failures bc of nix's strict build environment:
```
From worker startup: ERROR: IOError: bind: operation not permitted (EPERM)
```
I'm honestly not sure what the fix for this is. Removing the patch here (https://gist.github.com/samuela/257b66127bceffcc11453a6992a92d3d#file-1-6-bin-nix-L29) doesn't make any difference.
If anyone has any ideas, please do let me know!
Agreed, `x86_64-darwin` support should be a priority. However, I lack the hardware, software, and competence to be of much use. Thus I think what we need is someone that has all those three to step up, devise a patch, and add themselves as a maintainer.
Minor nitpick, this is not a bug. It is an enhancement request.
|
|
I'd be happy to invite you to build box access on my personal laptop for this purpose! I'll reach out over email. I took an initial stab at this so I'd be happy to contribute as well, just stuck on the Distributed errors currently. I know that we have an arch build box for members of the community (https://github.com/nix-community/aarch64-build-box). Does something like this exist for x86_64-darwin? If not we should certainly set one up! IIUC @domenkozar is working on an organized initiative to better macOS support. Perhaps we could collaborate towards getting a machine set up somewhere? |
|
The easiest is https://github.com/jtojnar/nixpkgs-fastmac |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/how-to-recreate-the-nix-build-sandbox/13378/1 |
Julia is not supported on Mac OS yet, but it's in the works: NixOS/nixpkgs#123394
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/need-special-build-of-nightly-julia-version/14504/4 |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
I'd be interested in taking this on, but would like to suggest a new approach. TL:DR; What if we didn't try to shoehorn in dependencies from nixpkgs, and just used BinaryBuilder as intended? I read through the linked discourse threads, and it seems one of the main issues here is that Julia already uses its own tool for portable, reproducible builds called BinaryBuilder.
But do we really need to skip BinaryBuilder? @ninjin doesn't seem to think so:
After cloning that and adding just three more lines, I successfully built and tested the whole package in a pure nix shell as the readme describes on my darwin-aarch64 machine. Of course, there's now the question of reproducibility, as BinaryBuilder downloads its dependencies from https://cache.julialang.org during the build step. But this shouldn't be too much of an issue. Some of these dependencies are checksummed, most are pinned to a version. As this step is done in the very beginning and can be invoked separately with I mainly used this post as a brain-dump and will try to see if I can actually implement this with my limited knowledge of nix, but if anyone has feedback, I'd be happy to hear it. Maybe I missed something very important here? |
stale
bot
removed
the
2.status: stale
|
Hi @iFreilicht , I haven't been active in the Julia package for a few months now but IIUC that sounds like an appealing path forward IMHO! There's been a looming question of how to handle BinaryBuilder packages within Nix (#20649), and this kind of solution might allow us to "kill two birds with one stone." IIUC this sounds quite similar to how we currently handle bazel packages in Nix: stage 1 pulls dependencies using a fixed-output derivation, and stage two completes the source build based on the output of stage 1. So yeah I'd say go for it -- sounds promising! @ninjin is a real pro with this stuff... I'd be curious to hear their thoughts as well? |
|
Alright, it's looking pretty good, see linked PR. Everything builds and installs well, the final julia seems functional from the little bit of playing around I've done. Almost all tests are successful as well after the installPhase, but a few are failing: I'm not particularly surprised about the Sockets tests; with no network connectivity that is bound to fail. But the Test and errorshow failures are curious. It seems backtraces don't work quite right? |
|
Closed by #205584. |
Describe the bug
Now that #123188 has landed, we have derivations for binary releases of julia versions 1.0.x and 1.6.x on x86_64-linux. It would be nice to expand platform support for these derivations, esp. for x86_64-darwin since that's what I have access to and use frequently.
I've taken a hacky first stab at this already: https://gist.github.com/samuela/257b66127bceffcc11453a6992a92d3d. Unfortunately, it gets hung up on test failures bc of nix's strict build environment:
I'm honestly not sure what the fix for this is. Removing the patch here (https://gist.github.com/samuela/257b66127bceffcc11453a6992a92d3d#file-1-6-bin-nix-L29) doesn't make any difference.
If anyone has any ideas, please do let me know!
Notify maintainers
cc @ninjin @raskin
Maintainer information:
The text was updated successfully, but these errors were encountered: