llvm-project
llvm-project copied to clipboard
apple
Enable aarch64-amazon-linux triple
add aarch64-amazon-linux triplet to allow compilation for Amazon Linux 2023 on Graviton CPU
This should address https://github.com/apple/llvm-project/issues/8227
@MaxDesiatov thank you for the quick review. Here is the upstream PR https://github.com/llvm/llvm-project/pull/82232
@alstair good catch about the comment above :-) Do you know what part of the build scripts invoke clang with incorrect triples ? I can try to modify the toolchain build scripts instead of clang itself
Do you know what part of the build scripts invoke clang with incorrect triples ? I can try to modify the toolchain build scripts instead of clang itself
Looking at #8227 I wonder whether there's a problem with the front-end figuring out what the triple should be in the first place, as CMake failed during a link step when trying to do
bin/clang CMakeFiles/cmTC_a5c7b.dir/testCCompiler.c.o -o cmTC_a5c7b
and if adding that triple to the list fixes it, that suggests that clang wasn't sure what triple it was supposed to be using in the first place for some reason. I don't know OTOH how it works out what the default triple should be, but I think that's probably where we should be looking for the problem here.
OK, so I think what happens is LLVM_DEFAULT_TARGET_TRIPLE is set from LLVM_HOST_TRIPLE, which is in turn set from LLVM_INFERRED_HOST_TRIPLE, which is initialised by llvm/cmake/modules/GetHostTriple.cmake, which, for things that are not in a small list of exceptions, runs a copy of config.guess.
Presumably this is generating the wrong result (I think it probably returns aarch64-unknown-linux-gnu), and I assume that the Triples arrays are in part an attempt to work around that problem.
My guess is that you should update GetHostTriple.cmake to work out the proper triple, since that would result in LLVM_DEFAULT_TARGET_TRIPLE being correct, which then means the compiler won't need to search. It looks like there was an intent to fix that by having the build process use the -dumpmachine option to clang instead of config.guess. See https://reviews.llvm.org/D109727, https://reviews.llvm.org/D109837, a07727199db0525e9d2df41e466a2a1611b3c8e1.
Presumably this is generating the wrong result (I think it probably returns
aarch64-unknown-linux-gnu), and I assume that theTriplesarrays are in part an attempt to work around that problem.
I was also seeing this issue when trying to build on Alpine Linux. It incorrectly inferred aarch64-unknown-linux-musl when I needed aarch64-alpine-linux-musl for things to work "the Alpine way".