Repository navigation
Conversation
…, implement box64 fallback, detect armhf multiarch support
Member
Author
|
Merged as part of: |
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
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.
Append the architecture name to loader binaries, implement box64 fallback, detect armhf multiarch support.
First commit of:
Deep rewrite of VirtualMachine making possible to have multiple loaders per engine (especially for armhf/amd64+box64 on arm64). There was already some code for the windows amd64 loader on i686 engine, but this code makes it possible to do it for other platforms from the ground up, and does it for box64.
In the same way, the CMake code is genericized as well, loader files use explicit extensions in all cases so it's trivial to have multiple loaders.
This also implements the armhf support detection, and automatically fallbacks on box64 when not supported.
This also bring little changes that are not anymore useful, like some rework of the multiarch loader which is already expected to disappear in next commits, but keeping that change unmodified reduces future merge conflicts from future commits to merge. I strongly prefer to keep it that way.
After that one, only two commits will have to be merged and we will be ready to merge @slipher's change.
I already verified that all commits from #2018 are building complete releases each. I don't want to break that and I prefer to avoid redoing hour long testing by not inserting random purity changes between this and the next commits.