This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Include <__config_site> from <__config>
ClosedPublic

Authored by phosek on Feb 26 2021, 12:27 PM.

Details

Reviewers
ldionne
jdoerfert
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rGc06a8f9caa51: [libc++] Include <__config_site> from <__config>
Summary

Prior to this patch, we would generate a fancy <config> header by
concatenating <
config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.

This patch removes that complexity and instead simply installs <config_site>
alongside the libc++ headers. <
config_site> is then included by <config>,
which is much simpler. Doing this also opens the door to having different
<
config_site> headers depending on the target, which was impossible before.

It does change the workflow for testing header-only changes to libc++.
Previously, we would run lit against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run ninja check-cxx-deps before running lit by
hand.

This commit was originally applied in 5d796645d and reverted in 48e4b0fd3
because it broke several bots. The issues should have been addressed now.

Diff Detail

Event Timeline

phosek created this revision.Feb 26 2021, 12:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 26 2021, 12:27 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
phosek requested review of this revision.Feb 26 2021, 12:27 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added subscribers: Restricted Project, sstefan1. · View Herald Transcript

@ldionne this is an attempt at reviving D89041, I tested this locally and it seems to be working, at least for the Fuchsia runtimes build. It might break out some parts of this patch to make it more manageable, like the s/-isystem/-cxx-isystem/ in compiler-rt.

I think it would be great to try it out again. To be honest, I've been meaning to try it out again (I had a similar patch locally), but I've been too scared to do so. Last time the world just exploded and I spent like a week trying to make heads or tail of the situation.

I'm entirely favorable to doing this, but can we try splitting out changes as much as possible? Ideally, we'd land everything before, and then at the end we'd land the libc++ changes, and only those.

Also, it would be awesome to set up a true runtimes build on our pre-commit CI infrastructure. The GCE instances we use could probably handle the load, they're very beefy. Would you be willing to help set that up?

curdeius added inline comments.
libcxx/cmake/Modules/HandleLibCXXABI.cmake
55–58

If it's always true, then the condition should be removed, no?

ldionne added inline comments.Mar 1 2021, 8:03 AM
libcxx/cmake/Modules/HandleLibCXXABI.cmake
55–58

I think at the time it was an attempt to make the diff as small as possible, since that change was already very risky. If we manage to split this out into smaller patches, then yeah, I think we could probably just remove this if and unconditionally execute its body.

phosek updated this revision to Diff 329712.Mar 10 2021, 10:55 AM

Minor drive-by comments. I'm extremely unlikely to voice either approval or disapproval in an official capacity. :)

libcxx/CMakeLists.txt
407

This comment is scary but uninformative. What "other projects" do you mean? By "these dependencies" do you mean the dependency from those other projects to the specific string "c++/v1" (in which case surely you should say They not We)? or by "these dependencies" do you mean one or more of lines 408-424?
Do you mean They should use LIBCXX_GENERATED_INCLUDE_DIR instead of hard-coding include/c++/v1?

libcxx/docs/TestingLibcxx.rst
44

Is running [ninja|make] cxx specifically not enough? (I'm guessing the answer is "yes, not enough.") That answer should be called out explicitly in the text.

libcxxabi/CMakeLists.txt
173

Lines 170 and 172 are identical except for /I versus -I. I know Microsoft's command-line compiler driver supports -I as a synonym for /I. So could we combine these five lines into one line using -I in both cases? Or is the slash character required because it's magic to CMake, or something like that?

phosek updated this revision to Diff 332838.Mar 23 2021, 6:00 PM
phosek marked an inline comment as done.
phosek marked an inline comment as done.
phosek added inline comments.
libcxx/docs/TestingLibcxx.rst
44

This section specifically is about using llvm-lit directly, if you're using ninja or make you can just run check-cxx.

phosek updated this revision to Diff 332839.Mar 23 2021, 6:05 PM
phosek marked an inline comment as done.

@ldionne I've already landed all changes that could be meaningfully carved out, would you be OK if we tried to land this again?

phosek updated this revision to Diff 332879.Mar 24 2021, 12:37 AM

Looks like presubmit checks are passing now.

Looks like presubmit checks are passing now.

I'm pretty sure we'll need the cxx-headers change in libcxxabi (D98367) to make this change, no? Otherwise, we might break some people building and testing libc++abi in funky ways. I'd also wait until https://reviews.llvm.org/D97888 has landed so that the pre-commit tests include the Runtimes build. But except for that, I think this is good and I'm excited/scared to try this again.

phosek updated this revision to Diff 334222.Mar 30 2021, 10:39 AM

Looks like presubmit checks are passing now.

I'm pretty sure we'll need the cxx-headers change in libcxxabi (D98367) to make this change, no? Otherwise, we might break some people building and testing libc++abi in funky ways. I'd also wait until https://reviews.llvm.org/D97888 has landed so that the pre-commit tests include the Runtimes build. But except for that, I think this is good and I'm excited/scared to try this again.

This should be ready to land now.

ldionne accepted this revision.Mar 30 2021, 12:39 PM

LGTM with nitpick (and assuming CI comes back green).

I still think we should watch out for any unintended consequence of this change. Basically, anyone including libcxx/include instead of the properly installed headers will now run into issues after this change (since __config_site will not have been included and thus won't be found). That's why this change has so much possibility for breakage. However, once that's fixed, we'll be in a much better place knowing that all users are using the correctly installed (and hence configured) libc++ headers.

libcxx/docs/TestingLibcxx.rst
42

This target name has been renamed since the original patch. It's now cxx-test-depends.

phosek updated this revision to Diff 334267.Mar 30 2021, 2:05 PM
phosek marked an inline comment as done.
This revision was not accepted when it landed; it landed in state Needs Review.Mar 30 2021, 2:06 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Mar 31 2021, 3:39 PM

We're seeing two test failures on macOS in bootstrap builds after this: https://bugs.chromium.org/p/chromium/issues/detail?id=1194745

We're seeing two test failures on macOS in bootstrap builds after this: https://bugs.chromium.org/p/chromium/issues/detail?id=1194745

D99706 should hopefully address this.

muiez added a subscriber: muiez.Apr 26 2021, 7:32 AM
muiez added inline comments.
libcxx/cmake/Modules/HandleLibCXXABI.cmake
66

Wouldn't this copy the libc++abi headers to include/c++/v1/include/c++/v1/ (on z/OS for example)? I ask because LIBCXX_GENERATED_INCLUDE_DIR is already set to ${LLVM_BINARY_DIR}/include/c++/v1 above. Nonetheless, the old change copies them to include/c++/v1 instead. In other words, was this intended?

phosek marked an inline comment as done.Apr 27 2021, 11:32 PM
phosek added inline comments.
libcxx/cmake/Modules/HandleLibCXXABI.cmake
66

This was unintended, thanks for spotting it, I fixed it in rGeea5cbc8583d0857e0a9e429c61f7e87122b4dd6.

I suspect this broke the OSS-Fuzz integration

Step #4: + ./libcxx/utils/ci/oss-fuzz.sh
Step #4: In file included from libcxx/test/libcxx/fuzzing/make_heap.pass.cpp:11:
Step #4: In file included from libcxx/include/algorithm:648:
Step #4: libcxx/include/__config:13:10: fatal error: '__config_site' file not found
Step #4: #include <__config_site>
Step #4:          ^~~~~~~~~~~~~~~
Step #4: 1 error generated.
Step #4: ********************************************************************************
Step #4: Failed to build.
Step #4: To reproduce, run:
Step #4: python infra/helper.py build_image llvm_libcxx
Step #4: python infra/helper.py build_fuzzers --sanitizer address --engine libfuzzer --architecture x86_64 llvm_libcxx
Step #4: ********************************************************************************
Finished Step #4
ERROR
ERROR: build step 4 "gcr.io/oss-fuzz/llvm_libcxx" failed: step exited with non-zero status: 1

See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32788

bjope added a subscriber: bjope.Jun 3 2021, 2:56 AM

I added some questions related to this in D103386 (as I started to see failures with not finding __config_siteafter that patch, but I guess it is related to this patch).

We been using -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++ when building clang. And we also use -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
We also build clang/llc for all targets, but we only build libcxx for a subset of targets (e.g. x86_64-unknown-linux-gnu).

When I only build libcxx for x86_64-unknown-linux-gnu, I only get a config_site file for that specific triple inside bin/../include/x86_64-unknown-linux-gnu/c++/v1/config_site in the build result.
But then when compiling for a target such as powerpc64le-unknown-linux-gnu (the test case added in D103386), when including bin/../include/c++/v1/stddef.h, that wants wants to include <__config_site>, I run into trouble because there is no such header for the powerpc64le-unknown-linux-gnu triple.

Is this kind of setup totally stupid and unsupported?
(I kind of understand that using libcxx for powerpc64le-unknown-linux-gnu when not building libcxx for that target kind of is like begging for problems, but I doubt the test case should depend on that, or if I override CLANG_DEFAULT_CXX_STDLIB)

Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding __config_site. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx.
Maybe this is as expected? Or maybe it has been forseen?

Should there perhaps always be some kind of generic __config_site that is used if there is not target override?

I added some questions related to this in D103386 (as I started to see failures with not finding __config_siteafter that patch, but I guess it is related to this patch).

We been using -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++ when building clang. And we also use -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
We also build clang/llc for all targets, but we only build libcxx for a subset of targets (e.g. x86_64-unknown-linux-gnu).

When I only build libcxx for x86_64-unknown-linux-gnu, I only get a config_site file for that specific triple inside bin/../include/x86_64-unknown-linux-gnu/c++/v1/config_site in the build result.
But then when compiling for a target such as powerpc64le-unknown-linux-gnu (the test case added in D103386), when including bin/../include/c++/v1/stddef.h, that wants wants to include <__config_site>, I run into trouble because there is no such header for the powerpc64le-unknown-linux-gnu triple.

Is this kind of setup totally stupid and unsupported?
(I kind of understand that using libcxx for powerpc64le-unknown-linux-gnu when not building libcxx for that target kind of is like begging for problems, but I doubt the test case should depend on that, or if I override CLANG_DEFAULT_CXX_STDLIB)

Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding __config_site. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx.
Maybe this is as expected? Or maybe it has been forseen?

Should there perhaps always be some kind of generic __config_site that is used if there is not target override?

I still have these questions. Is there anyone that could help clarifying this a bit, how is it supposed to work?

phosek marked an inline comment as done.Jun 23 2021, 12:44 AM

I added some questions related to this in D103386 (as I started to see failures with not finding __config_siteafter that patch, but I guess it is related to this patch).

We been using -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++ when building clang. And we also use -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
We also build clang/llc for all targets, but we only build libcxx for a subset of targets (e.g. x86_64-unknown-linux-gnu).

When I only build libcxx for x86_64-unknown-linux-gnu, I only get a config_site file for that specific triple inside bin/../include/x86_64-unknown-linux-gnu/c++/v1/config_site in the build result.
But then when compiling for a target such as powerpc64le-unknown-linux-gnu (the test case added in D103386), when including bin/../include/c++/v1/stddef.h, that wants wants to include <__config_site>, I run into trouble because there is no such header for the powerpc64le-unknown-linux-gnu triple.

Is this kind of setup totally stupid and unsupported?
(I kind of understand that using libcxx for powerpc64le-unknown-linux-gnu when not building libcxx for that target kind of is like begging for problems, but I doubt the test case should depend on that, or if I override CLANG_DEFAULT_CXX_STDLIB)

Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding __config_site. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx.
Maybe this is as expected? Or maybe it has been forseen?

Should there perhaps always be some kind of generic __config_site that is used if there is not target override?

I still have these questions. Is there anyone that could help clarifying this a bit, how is it supposed to work?

I missed your question earlier so I apologize for the belated response.

This is not the scenario that I considered when implementing this change but it makes sense. We could generate a generic fallback __config_site, my only concern is that it could potentially mask a case where the target __config_site is missing where today you'd get an include error whereas with the fallback __config_site you might see more subtle issues.

We could put it behind a CMake option that's going to be opt-in, for example LIBCXX_GENERIC_CONFIG_SITE, would that work?

@ldionne do you have any other ideas? Would this be OK with you?

bjope added a comment.Jun 23 2021, 5:56 AM

I added some questions related to this in D103386 (as I started to see failures with not finding __config_siteafter that patch, but I guess it is related to this patch).

We been using -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++ when building clang. And we also use -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
We also build clang/llc for all targets, but we only build libcxx for a subset of targets (e.g. x86_64-unknown-linux-gnu).

When I only build libcxx for x86_64-unknown-linux-gnu, I only get a config_site file for that specific triple inside bin/../include/x86_64-unknown-linux-gnu/c++/v1/config_site in the build result.
But then when compiling for a target such as powerpc64le-unknown-linux-gnu (the test case added in D103386), when including bin/../include/c++/v1/stddef.h, that wants wants to include <__config_site>, I run into trouble because there is no such header for the powerpc64le-unknown-linux-gnu triple.

Is this kind of setup totally stupid and unsupported?
(I kind of understand that using libcxx for powerpc64le-unknown-linux-gnu when not building libcxx for that target kind of is like begging for problems, but I doubt the test case should depend on that, or if I override CLANG_DEFAULT_CXX_STDLIB)

Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding __config_site. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx.
Maybe this is as expected? Or maybe it has been forseen?

Should there perhaps always be some kind of generic __config_site that is used if there is not target override?

I still have these questions. Is there anyone that could help clarifying this a bit, how is it supposed to work?

I missed your question earlier so I apologize for the belated response.

This is not the scenario that I considered when implementing this change but it makes sense. We could generate a generic fallback __config_site, my only concern is that it could potentially mask a case where the target __config_site is missing where today you'd get an include error whereas with the fallback __config_site you might see more subtle issues.

We could put it behind a CMake option that's going to be opt-in, for example LIBCXX_GENERIC_CONFIG_SITE, would that work?

Just to understand, the idea is to put the generic file in include/c++/v1/ and rely on that if there is a target specific override that will be included instead (based on order of include paths)?

I do not have a problem with hiding such a thing behind a cmake option.

We could put it behind a CMake option that's going to be opt-in, for example LIBCXX_GENERIC_CONFIG_SITE, would that work?

@ldionne do you have any other ideas? Would this be OK with you?

Stumbled upon this months later while clearing my email queue, I hope the discussion is still relevant.

@bjope What is the intent when compiling for --target=powerpc64le-unknown-linux-gnu with a library that has only been built for x86_64-unknown-linux-gnu? Is the intent that the __config_site used for powerpc64le-unknown-linux-gnu is the same as the one for x86_64-unknown-linux-gnu? To me, that sounds like something we can't really guess. I think what I'm wondering here is why you're using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON at all.

Having a fallback is indeed tricky because we really want to avoid at all costs using the wrong __config_site by mistake (this could lead to incredibly tricky errors including ABI breaks). I would also really like to avoid adding an opt-in for this - there has to be a better solution.

bjope added a comment.Sep 22 2021, 8:51 AM

We could put it behind a CMake option that's going to be opt-in, for example LIBCXX_GENERIC_CONFIG_SITE, would that work?

@ldionne do you have any other ideas? Would this be OK with you?

Stumbled upon this months later while clearing my email queue, I hope the discussion is still relevant.

@bjope What is the intent when compiling for --target=powerpc64le-unknown-linux-gnu with a library that has only been built for x86_64-unknown-linux-gnu? Is the intent that the __config_site used for powerpc64le-unknown-linux-gnu is the same as the one for x86_64-unknown-linux-gnu? To me, that sounds like something we can't really guess. I think what I'm wondering here is why you're using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON at all.

Having a fallback is indeed tricky because we really want to avoid at all costs using the wrong __config_site by mistake (this could lead to incredibly tricky errors including ABI breaks). I would also really like to avoid adding an opt-in for this - there has to be a better solution.

Not sure exactly the history related to using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON, but out downstream compiler has support for a couple of different DSP targets and then we also support x86_64-unknown-linux-gnu (some users are basically using that for unittests running on the build server). So our release includes builtins/runtimes for those different targets.
However, we do not limit LLVM_TARGETS_TO_BUILD to only those target when we build/test/release the compiler, so clang will support targets such as powerpc (but we do not build/release any runtimes for powerpc).

If I recall correctly one of the problems that we started to see with this commit was that the test case clang/test/CodeGen/ppc-xmmintrin.c started to fail. That is the test case that is using powerpc64le-unknown-linux-gnu, and that would fail with fatal error: '__config_site' file not found.
So we could not use ninja check-all with that build setup.

Our current "workaround" is to avoid using -DCLANG_DEFAULT_CXX_STDLIB=libc++. So we kind of postponed the idea of building the compiler with libc++.

If I recall correctly one of the problems that we started to see with this commit was that the test case clang/test/CodeGen/ppc-xmmintrin.c started to fail. That is the test case that is using powerpc64le-unknown-linux-gnu, and that would fail with fatal error: '__config_site' file not found.
So we could not use ninja check-all with that build setup.

Our current "workaround" is to avoid using -DCLANG_DEFAULT_CXX_STDLIB=libc++. So we kind of postponed the idea of building the compiler with libc++.

That sounds to me like that testcase needs to be adjusted so that it's not reliant on the surrounding setup - the clang tests shouldn't rely on clang itself having a working C++ standard library available at all, in general.

If I recall correctly one of the problems that we started to see with this commit was that the test case clang/test/CodeGen/ppc-xmmintrin.c started to fail. That is the test case that is using powerpc64le-unknown-linux-gnu, and that would fail with fatal error: '__config_site' file not found.
So we could not use ninja check-all with that build setup.

Our current "workaround" is to avoid using -DCLANG_DEFAULT_CXX_STDLIB=libc++. So we kind of postponed the idea of building the compiler with libc++.

That sounds to me like that testcase needs to be adjusted so that it's not reliant on the surrounding setup - the clang tests shouldn't rely on clang itself having a working C++ standard library available at all, in general.

I agree, that looks like an issue with the test that should be addressed.

Agreed with @phosek and @mstorsjo. Also, I looked at ppc-xmmintrin.c and traced down the includes, and I don't see what would cause this issue. @bjope if you'd like to try to -DCLANG_DEFAULT_CXX_STDLIB=libc++ again, I'll do my best to help you troubleshoot the issue. If you do, it's easiest to reach out to me on Discord in the #libcxx channel.

Agreed with @phosek and @mstorsjo. Also, I looked at ppc-xmmintrin.c and traced down the includes, and I don't see what would cause this issue. @bjope if you'd like to try to -DCLANG_DEFAULT_CXX_STDLIB=libc++ again, I'll do my best to help you troubleshoot the issue. If you do, it's easiest to reach out to me on Discord in the #libcxx channel.

I actually started out by complaining about the test case here https://reviews.llvm.org/D103386#2790821 but I don't think it was corrected.

So that was one of the reasons for starting to ask questions in this review.

But I also wanted to know how this is supposed to work (or what shouldn't work) in a broader perspective. And there was also this other scenario that isn't helped out by adjusting a lit test in the llvm-project repo:

Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding __config_site. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx. Maybe this is as expected? Or maybe it has been forseen?

Hi, I'm hacking on trying to bootstrap a build of clang from sources linked against musl. I'm hitting a curious set of failures trying to bootstrap libcxxabi:

llvm-project/libcxx/include/__config:13:10: fatal error: '__config_site' file not found
#include <__config_site>

@compnerd mentioned this commit. It no longer can be reverted cleanly, but if I check out the commit before this, I no longer have this error bootstrapping.

(This isn't necessarily a regression; my scripts never worked on the first place. I only started writing them recently; much later than when this landed. That said, bootstrapping seems a bit trick at the moment and it's not clear how to fix).

Hi, I'm hacking on trying to bootstrap a build of clang from sources linked against musl. I'm hitting a curious set of failures trying to bootstrap libcxxabi:

llvm-project/libcxx/include/__config:13:10: fatal error: '__config_site' file not found
#include <__config_site>

@compnerd mentioned this commit. It no longer can be reverted cleanly, but if I check out the commit before this, I no longer have this error bootstrapping.

(This isn't necessarily a regression; my scripts never worked on the first place. I only started writing them recently; much later than when this landed. That said, bootstrapping seems a bit trick at the moment and it's not clear how to fix).

include/__config includes the generated include/x86_64-unknown-linux-gnu/c++/v1/__config_site.
__config_site has target specific customization.
clang --target=xxx using include/yyy/c++/v1/__config_site does not guarantee to work.

In practice, we can think that xxx and yyy may be similar enough and it may work if you just copy include/yyy/c++/v1/__config_site to include/xxx/c++/v1/__config_site

@nickdesaulniers More generally, you must be setting -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON when you build? Or is that the default on Linux now? If you're setting it explicitly, then you probably don't want to be doing that. LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is explicitly meant to have one include/ and lib/ dir for each target. If that's not your intent, then just use the good old way of doing things, i.e. just a single include/c++/v1 directory with all the headers, including the __config_site header. If LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is the default on Linux, then perhaps you should explicitly specify LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF.