[libcxx][ci] In picolib build, ask clang for the normalised triple#90722
[libcxx][ci] In picolib build, ask clang for the normalised triple#90722DavidSpickett merged 2 commits intollvm:mainfrom
Conversation
This is needed for a workaround to make sure the link later succeeds. I don't know the reason for that but it is definitely needed. llvm#89234 will/wants to correct the triple normalisation for -none- and this means that clang prior to 19, and clang 19 and above will have different answers and therefore different library paths. I don't want to bootstrap a clang just for libcxx CI, or require that anyone building for Arm do the same, so ask the compiler what the triple should be. This will be compatible with 17 and 19 when we do update to that version. I'm assuming $CC is what anyone locally would set to override the compiler, and `cc` is the binary name in our CI containers. It's not perfect but it should cover most use cases.
|
@llvm/pr-subscribers-libcxx Author: David Spickett (DavidSpickett) ChangesThis is needed for a workaround to make sure the link later succeeds. I don't know the reason for that but it is definitely needed. #89234 will/wants to correct the triple normalisation for -none- and this means that clang prior to 19, and clang 19 and above will have different answers and therefore different library paths. I don't want to bootstrap a clang just for libcxx CI, or require that anyone building for Arm do the same, so ask the compiler what the triple should be. This will be compatible with 17 and 19 when we do update to that version. I'm assuming $CC is what anyone locally would set to override the compiler, and Full diff: https://github.com/llvm/llvm-project/pull/90722.diff 1 Files Affected:
diff --git a/libcxx/utils/ci/run-buildbot b/libcxx/utils/ci/run-buildbot
index 60307a7d4f350a..132c98486de430 100755
--- a/libcxx/utils/ci/run-buildbot
+++ b/libcxx/utils/ci/run-buildbot
@@ -217,7 +217,19 @@ function test-armv7m-picolibc() {
"${@}"
${NINJA} -vC "${BUILD_DIR}/compiler-rt" install
- mv "${BUILD_DIR}/install/lib/armv7m-none-unknown-eabi"/* "${BUILD_DIR}/install/lib"
+
+ # Prior to clang 19, armv7m-none-eabi normalised to armv7m-none-unknown-eabi.
+ # clang 19 changed this to armv7m-unknown-none-eabi. So for as long as 18.x
+ # is supported, we have to ask clang what the triple will be.
+ if [ ! -z "${CC}" ]
+ then
+ C_COMPILER=${CC};
+ else
+ C_COMPILER=cc;
+ fi
+ NORMALISED_TARGET_TRIPLE=$(${C_COMPILER} --target=armv7m-none-eabi -print-target-triple)
+ # Without this step linking fails later in the build.
+ mv "${BUILD_DIR}/install/lib/${NORMALISED_TARGET_TRIPLE}"/* "${BUILD_DIR}/install/lib"
check-runtimes
}
|
|
This should work for the current state and when #89638 lands. |
|
And if anyone is brave enough to build with gcc: At least they will be pointed right to the line they need to hack to make it work. |
These scripts are so llvm-hardcoded, so it won't be a big problem to introduce one more ;) LGTM. |
peterwaller-arm
left a comment
There was a problem hiding this comment.
LGTM, optional nits, since you might have valid reasons for writing it as you did.
|
I'm going to land this without libcxx approval given that it is limited to the picolib build, is required to keep the CI green once the other PR lands, and has passed existing CI (aside from AIX 32 bit that I assume is a pre-existing issue). Post-commit review welcome of course. |
This is needed for a workaround to make sure the link later succeeds. I don't know the reason for that but it is definitely needed.
#89234 will/wants to correct the triple normalisation for -none- and this means that clang prior to 19, and clang 19 and above will have different answers and therefore different library paths.
I don't want to bootstrap a clang just for libcxx CI, or require that anyone building for Arm do the same, so ask the compiler what the triple should be.
This will be compatible with 17 and 19 when we do update to that version.
I'm assuming $CC is what anyone locally would set to override the compiler, and
ccis the binary name in our CI containers. It's not perfect but it should cover most use cases.