clang.bbclass: add clang-native to BASE_DEFAULT_DEPS #1140
Conversation
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
Add it for target builds in:
BASE_DEFAULT_DEPS:append:class-target:toolchain-clang:class-target
because ${MLPREFIX}clang-cross-${TARGET_ARCH} contains a broken symlink
to clang binary provided by clang-native and then in case someone
changes e.g.
TC_CXX_RUNTIME = "llvm"
to
TC_CXX_RUNTIME:class-target = "llvm"
then both clang-native and clang-cross-${TARGET_ARCH} are correctly
rebuilt, but unfortunately the hashequiv output hash of
clang-cross-${TARGET_ARCH} doesn't change (because the broken symlink
is still the same), so e.g. gptfdisk which depends on "equivalent"
clang-cross from BASE_DEFAULT_DEPS doesn't get rebuilt, but then it
still links with libc++.so.1 while in clean build without sstate and
hashequiv it will link with libstdc++.so.6 (because TC_CXX_RUNTIME
affects only clang-native and the override for class-target doesn't
work as one might expect).
This might need some bigger changes in hashequiv to have special
handlink of broken symlinks in the output, if the symlink target is
provided by some dependency, we should include the hash of the symlink
target to make sure the outhash changes even when something deeper
in dependency tree changed the target binary (or error out when there
is no direct dependency of the provider).
clang-cross from oe-core master doesn't have this issue, because it
contains the actual binary from clang-native after:
openembedded/openembedded-core@3b0128f
so the outhash is changed when this binary is changed.
Signed-off-by: Martin Jansa <[email protected]>
Contributor
Author
|
More proper solution for cross.bbclass: will send it to oe-core after more testing, but it will be a while before it gets backported to scarthgap, so this work around might be still useful. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Add it for target builds in:
BASE_DEFAULT_DEPS:append:class-target:toolchain-clang:class-target
because ${MLPREFIX}clang-cross-${TARGET_ARCH} contains a broken symlink to clang binary provided by clang-native and then in case someone changes e.g.
TC_CXX_RUNTIME = "llvm"
to
TC_CXX_RUNTIME:class-target = "llvm"
then both clang-native and clang-cross-${TARGET_ARCH} are correctly rebuilt, but unfortunately the hashequiv output hash of clang-cross-${TARGET_ARCH} doesn't change (because the broken symlink is still the same), so e.g. gptfdisk which depends on "equivalent" clang-cross from BASE_DEFAULT_DEPS doesn't get rebuilt, but then it still links with libc++.so.1 while in clean build without sstate and hashequiv it will link with libstdc++.so.6 (because TC_CXX_RUNTIME affects only clang-native and the override for class-target doesn't work as one might expect).
This might need some bigger changes in hashequiv to have special handlink of broken symlinks in the output, if the symlink target is provided by some dependency, we should include the hash of the symlink target to make sure the outhash changes even when something deeper in dependency tree changed the target binary (or error out when there is no direct dependency of the provider).
clang-cross from oe-core master doesn't have this issue, because it contains the actual binary from clang-native after: openembedded/openembedded-core@3b0128f so the outhash is changed when this binary is changed.