Update esysroot patch to fix prefix and Canadian Cross issues #7
Conversation
This file contains 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
Closes: https://bugs.gentoo.org/942672 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Closes: https://bugs.gentoo.org/942672 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
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.
This addresses bug #942672 by comparing
ESYSROOTwithBROOTrather than merely checking whetherESYSROOTis empty or/. Although both variables are set by Portage, I didn't want to assume they were fully normalised, so I applied libiberty'slrealpathhelper.It now also ignores
ESYSROOTifCHOSTis set but doesn't match the toolchain's target machine. This is necessary for a Canadian Cross. In that case, two cross-compilers are invoked, but only the one matchingCHOSTshould have its sysroot set byESYSROOT.I've been slightly unsure whether this is the best approach. Another would be to check whether
CTARGETdoes match if set. OrCHOSTcould be compared withCTARGET.CTARGETis rarely used though, and I didn't want to assume it would be in every case of this. The downside to comparing with the target machine is that it breaks if the compiler has been invoked using a different name, e.g. x86_64-cross-linux-gnu-gcc as a symlink to x86_64-pc-linux-gnu-gcc for a cheap "native cross" solution. I could be swayed here, so feedback welcome.The code also moved up a few lines to accommodate another patch I'm going to submit.