In D72109#1876189, @serge-sans-paille wrote:

@mgorny can you try with https://reviews.llvm.org/D74602 applied?

This broke standalone build of clang. It's trying to write into /include (as in, root directory) now! My guess is that LLVM_BINARY_DIR is undefined at this point of standalone build, later it might be defined to point to directory where LLVM was installed which also wouldn't be correct.

@broadwaylamb, I've requested backporting this to 10.x: https://bugs.llvm.org/show_bug.cgi?id=44905. However, i wasn't able to find to find you on Bugzilla and CC you. Could you confirm whether it's fine to backport, please?

Gentoo, using the ebuilds. I think the most relevant is how libc++abi is configured:

Added tlsbase.

This seems to have broken NetBSD:

I can confirm the tests pass both on i386 and amd64 for me, with this patch.

While it fixes i386 tests, it seems to break amd64 now. Do you need me to paste the output or can you reproduce?

Still LGTM.

Removed the aforementioned chunk.

In D69169#1851415, @broadwaylamb wrote:

Could you please show me how you're building libc++? I'm having trouble reproducing the issue.

The question is, does this break any of the platform hacks? ;-)

I'm actually trying to make 10.0.0 a little less broken for Gentoo.

That said, can we revert this from 10.x branch, please?

This change broke stand-alone builds. They now try to use libc++abi from the wrong directory, instead of system instance:

I suppose you need to make the timeout branch entirely separate from the non-timeout branch, as the variable assignment does not take place then.

In D73249#1836528, @protze.joachim wrote:

From my understanding of cmake scoping, this variable is visible because it's a cached option?

Yes, indeed the goal is to unbreak 10.x. I'd also agree to making bigger changes in 11.x separately.

In D73249#1835526, @Hahnfeld wrote:

I'm not sure LIBOMP_OMPT_SUPPORT is guaranteed to be there yet when defined in runtime/.

Well, it looks correct to me. Not sure if it's the best approach but it can be refined in the future.

I'm afraid this breaks stuff. TableGen built against libc++ after this change misbehaves:

Besides the mentioned misindent, the CMake code looks correct. Could you test whether it works with standalone (out-of-LLVM) builds as well?

This broke NetBSD buildbot:

Thanks!

Also older versions of gcc. This broke bootstrap on NetBSD: http://lab.llvm.org:8014/builders/netbsd-amd64/builds/771/steps/ninja%20build%20local/logs/stdio

Is there a way to get the basename from ZLIB_LIBRARY by any chance? Not saying it's actually necessary, just wondering.

LGTM, presuming you've tested it. If you need me to do a second test run, lemme know.

Besides missing LZMA, looks good to me. However, I suspect you may want to wait for a second opinion ;-).

Switch to using %run_nomprotect instead of extra %paxctl. This should be more consistent and should avoid potential issues with : on Windows.

I've tried fixing llvm-config but that's non-trivial. If I fix it to correctly recognize which components are included in dylib, and return other libraries directly, it just uncovers other problems.

In D58892#1783042, @MaskRay wrote:

In D58892#1783029, @mgorny wrote:

I know I'm late to the party but this change thoroughly destroyed NetBSD support. The NetBSD loader doesn't support having more than two PT_LOAD sections. -z norosegment helped with that so far but after this change practically everything fails to run.

This seems to be a very serious limitation. I have difficult to understand how such limitation could exist at all, but I think this should be straightforward to fix.

I know I'm late to the party but this change thoroughly destroyed NetBSD support. The NetBSD loader doesn't support having more than two PT_LOAD sections. -z norosegment helped with that so far but after this change practically everything fails to run.

I'm going to be blunt but if you dislike what LLVM does, improve that rather than proliferating inconsistencies between subprojects.