Add images with both "host" and "target" crossroots in one image.#913
Merged
directhex merged 4 commits intodotnet:mainfrom Aug 21, 2023
Merged
Add images with both "host" and "target" crossroots in one image.#913directhex merged 4 commits intodotnet:mainfrom
directhex merged 4 commits intodotnet:mainfrom
Conversation
This is required in some cases - e.g. compiling node.js for ARM64/Alpine, and the ever-broken ARM64 runtime perf lane (where we need headers for ARM64 available alongside linkable libraries for AMD64, depending on the build phase). As is, we've achieved the same result largely by accident in the pre-Mariner build images, where we have enough x64 in the host OS to link successfully, and the ARM64 files in the crossroot. The precedent on this is dotnet#901 which fixed our Android cross-compiler builds, by offering both Android and $HOST in the same system If at some point in the future we move from building on x64 to building on ARM64, we will need the equivalent images for that.
ghost
added
mthalman
reviewed
Aug 18, 2023
Contributor
Author
|
I've validated these images locally in dotnet/node#36 - I was able to cross-compile for Musl for the first time, and arm64 Ubuntu on Mariner without gross accidental functioning via the old Ubuntu images. |
mthalman
reviewed
Aug 21, 2023
Co-authored-by: Matt Thalman <[email protected]>
mthalman
approved these changes
Aug 21, 2023
akoeplinger
reviewed
Aug 22, 2023
| "osVersion": "cbl-mariner2.0", | ||
| "tags": { | ||
| "cbl-mariner-2.0-cross-biarch-amd64-amd64-alpine-$(System:TimeStamp)-$(System:DockerfileGitCommitSha)": {}, | ||
| "cbl-mariner-2.0-cross-biarch-amd64-amd64-alpine$(FloatingTagSuffix)": {} |
Member
There was a problem hiding this comment.
is the amd64-amd64 a typo? Or does it mean cross compiling from amd64 to amd64?
Contributor
Author
|
No. amd64 primary crossrootfs, amd64-alpine secondary
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is required in some cases - e.g. compiling node.js for ARM64/Alpine, and the ever-broken ARM64 runtime perf lane (where we need headers for ARM64 available alongside linkable libraries for AMD64, depending on the build phase).
As is, we've achieved the same result largely by accident in the pre-Mariner build images, where we have enough x64 in the host OS to link successfully, and the ARM64 files in the crossroot.
The precedent on this is #901 which fixed our Android cross-compiler builds, by offering both Android and $HOST in the same system
If at some point in the future we move from building on x64 to building on ARM64, we will need the equivalent images for that.