corretto: fix Darwin build #290808
corretto: fix Darwin build #290808
Conversation
ofborg
bot
added
6.topic: darwin
|
@ofborg build corretto11 |
| @@ -58,6 +58,8 @@ jdk.overrideAttrs (finalAttrs: oldAttrs: { | |||
| # Corretto's actual built is triggered via `gradle`. | |||
| gradle --console=plain --no-daemon ${task} | |||
|
|
|||
| set -xv | |||
There was a problem hiding this comment.
Is this needed to fix the Darwin build?
There was a problem hiding this comment.
No, this is needed for me because I don't have access to macos so I rely on ofBorg results.
There was a problem hiding this comment.
Ok then it doesn't need to be in the commit. You can request the help of @NixOS/darwin-maintainers to fix the remaining Darwin issues.
|
I guess this is unlikely to work, since building the JDK from source on Darwin requires Xcode. Also, |
Ah, good hint. Thank you. |
rollf
force-pushed
the
corretto-macos
branch
from
a9eed52 to
bb3c412
Compare
|
This PR was motivated by issue #290341 ("Corretto build fails on macos"). Corretto was originally added (by me) in PR #263736 ( follow-up was #272226, Corretto is Amazon's Java distribution). It seems that that the original PR never went through ofBorg's testing of the compilation on Darwin (at least I can't see anything in the PR Conversation). Currently, Corretto can't build on Darwin. I do not have access to a Mac so I can't work in this. For reference, here is the gradle task that I think would build the tar.gz'ed jdk on Darwin. @NixOS/darwin-maintainers Do you mind having a look into this? |
As indicated, #263736 also failed to build on darwin: https://github.com/NixOS/nixpkgs/runs/18953283987 I guess the reviewers just ignored the neutral checks...
The build phase is not OK: https://github.com/NixOS/nixpkgs/pull/290808/checks?check_run_id=22019011776 |
|
@GrahamcOfBorg build corretto11 |
|
Result of |
|
Other than building locally, how can I help you @rollf ? |
|
Here's the run log for |
|
Hi @pcasaretto , thanks for chiming in. Well yes, I think fixing the build locally would be great. I can only guess from here. Thanks for adding the run log. I am blindly guessing: Maybe adding
Mind the comment above, too. |
|
Some progress: # dontConfigure = true;
configurePhase = ''
runHook preConfigure
bash configure --with-xcode-path=$(xcode-select -p)
runHook postConfigure
'';Then I ran into an error for a missing "zip" executable which was easy to resolve adding "zip" to "nativeBuildInputs". |
|
It seems |
|
Oh, wait, there's a package for it pkgs/os-specific/darwin/xattr/default.nix |
|
Adding "xattr" and "fileset" lead me to: Latest build log: https://gist.github.com/pcasaretto/c7f284a18c13e3b3213d99d6b9b3ab3f Will try to resume over the weekend. |
|
Funny thing is that the docs mention full XCode is NOT required but there is a direct dependency on the "metal" executable. |
|
@pcasaretto Thanks for your efforts! I invited you to my fork. Could you share your achievements so far within the One thing I have thought about: What about not forwarding, say, |
|
Sure! Adding a trace for what package is being used for building, for example, correto17 on darwin gives me |
|
Upon further investigation (using the NIX_DEBUG env var) I found that apparently, the correct instructions are being given to clang. However, it cannot find the proper xnu headers it needs for my current architecture (arm64). And when I forced that to happen using: that messed up the order of the imports, triggering this code https://reviews.llvm.org/D131441 |
|
Tried a couple of things like: But I always end up without ptrauth.h or the stdlib. |
|
@pcasaretto It looks like that ptrauth is baked into llvm but it is not yet upstreamed: #188322 (comment) and here is the big pull request which might soon land: llvm/llvm-project#65996 As a result, it is currently not possible to create an aarch64-darwin source build because we need to wait until the pr lands in llvm and then in nixpkgs. I was once in the same situation as you were and I admire your persistence and commitment to get this source build working. However, I want to raise the question if it does not make more sense to just provide binary builds on darwin because
Finally, I don't want to discourage you completely and therfore you could try building it for x86_64-darwin on an aarch64 machine with |
|
Thanks once again @pcasaretto for your work here. Thank you, @tricktron, also for your feedback. |
|
That makes a lot of sense. Thanks! |
|
@pcasaretto I'd personally rather wait and see whether corretto could be build by us entirely instead of providing binary builds. While the "corretto" docs say that aarch64 is unsupported, aarch64 macos builds are actually provided. My impression from previously working with the corretto code base is that some of the docs are not up to date - corretto is a fork but the docs sometimes still assume jdk. I'm think now that I could try to build myself with |
|
Using that flag I was able to advance further into the buildPhase. I thought nix builds were pure? Full log: https://gist.github.com/pcasaretto/e2aed869acd7ac07f0dff44f808368bc |
|
invoking clang by itself shows an environment where the the Apple Frameworks seem to be configured correctly. |
|
The problem is taming this part of the configure phase https://github.com/corretto/corretto-11/blob/22d3ba74941d48a775ef44c69e1a8e92d099cb8e/make/autoconf/basic.m4#L241-L308 |
|
The particular error you have seems to stem from mixing SDKs. (FYI: Your two links link to From the code you linked, some ideas: Maybe run with Can you also share your current state (i.e push)? |
|
It makes sense that they were mixed, part of the build used my machine's actual XCode.app. |
I think they are mutually exclusive. The experience of using Xcode with nixpkgs is really poor (it's not nixpkgs fault). |
|
About Using |
|
Some good news! It tooks a customized xnu derivation and some extra dependencies but I think I can see the light at the end of the tunnel. |
|
Made some progress but still stuck on the zip error. |
|
Mh, that zip error is strange. Maybe you could have a look into the failed build folder ( It looks like the osxsecurity & the zip libs should have been built both, though:
|
|
As it turns out, that zip error is misleading. It seems when an error occurs the build tries to update or delete support/src.zip and fails to do so. |
|
@pcasaretto I have added |
wegank
added
the
2.status: merge conflict
|
I am stepping down from this. Vacation's over. |
|
@pcasaretto Thank your very much for your work here. I had already ping'ed the darwin maintainers above so I don't want to do this again here. If anyone wants to contribute, feel free! |
|
Personally, I think it would be worth considering @tricktron's suggestion and packaging the binaries for macos. It seems like even if we can get a source build working it's likely to be flaky and a pain to maintain. |
wegank
added
the
2.status: stale
Description of changes
This PR is motiaved by #290341 .
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.