I think this is ready to be commit, if additional changes are needed let me know.

@smeenai thanks for submitting!

Rather than creating LLVMgold.so as this change does, @beanz suggested we use a known LTO capable linker, lld. See D62279..

In D61203#1517023, @smeenai wrote:

@winksaville I can commit this for you on Monday if no one's gotten to it before.

@smeenai, who/how does this get submitted?

Update commit message and rebase on newer master

So this compiles and improves on what we currently have and as such I think it should be
merged, although there maybe other solutions. It still fails ninja stage2-check-all with the
gtest problem which @beanz is working on resolving.

Added libcxxabi and rebased

In D62279#1514596, @beanz wrote:

@winksaville I've figured out how to resolve the gtest issue, but unfortunately that isn't good enough to get the check-runtimes target working. A change went in back in February (rL353601), which breaks running compiler-rt's tests when building a distribution in non-trivial ways, which will unfortunately be difficult to resolve.

I will land the gtest fix sometime today, and I'm going to start working toward getting the larger issue resolved, although that is going to take some time.

Are you still having that issue after rL361436? That should have resolved that problem. The issue isn't that gtest is missing from the bootstrap, but rather that it was missing from the dependencies for the runtime libraries.

Adding libcxxabi worked and ninja stage2-distribution succeeded but I then ran ninja check-all and from within stage2-bins/ but that failed:

[1072/1526] cd /home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins && /usr/bin/cmake --build /home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins/ --target check-runtimes --config RelWithDebInfo
ninja: error: '/home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/lib/libgtest.a', needed by 'compiler-rt/lib/asan/tests/ASAN_INST_TEST_OBJECTS.gtest-all.cc.x86_64-calls.o', missing and no known rule to make it
FAILED: runtimes/CMakeFiles/check-runtimes 
cd /home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins && /usr/bin/cmake --build /home/wink/prgs/llvm/llvm-project/build-dist-use-lto-capable-linker-and-add-libcxxabi/tools/clang/stage2-bins/runtimes/runtimes-bins/ --target check-runtimes --config RelWithDebInfo

Chris, I was going to report that libcxxabi_shared was missing as I thought you had added it to in LLVM_ENABLE_RUNTIMES, but you hadn't so abandoning and trying again.

I actually really appreciate you trying this out and reporting back with such detailed feedback on your experience. Thank you for your patience, and I'm sorry if I'm being a bit of a pain.

In D62215#1510933, @beanz wrote:

Adding "libcxxabi" to LLVM_ENABLE_RUNTIMES is fine, but the other changes to the DistributionExample are only needed because you chose to use gold, which is a configuration-specific decision that is not representative of how most people will build, therefore it shouldn't be in the example.

I'm also not sure the PLUGIN_TOOL line is correct. That seems to assume that you either set LLVM_ENABLE_LLVM_DYLIB, or have libLLVM pre-installed, which I don't think most people do.

This may not "correct" but I had to do these to get ninja stage2-distribution to complete on my computer.

In D62040#1508937, @beanz wrote:

@winksaville I just committed an update to the DistributionExamples a minute ago that should get them working as long as you aren't using a Darwin host. If you are using a Darwin host you need D62155 as well.

In D62040#1507831, @beanz wrote:

@winksaville, sorry those cache files pre-date the monorepo, and they haven’t been updated to support it. I will try and get a patch to update them today.

What have I done wrong?

I'm trying to test the distribution commands from lines 65-67, I first do the cmake:

$ cd ~/prgs/llvm/llvm-project
$ mkdir build
$ cd build
$ cmake -G Ninja -C ../clang/cmake/caches/DistributionExample.cmake ../llvm
loading initial cache file ../clang/cmake/caches/DistributionExample.cmake
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
...
-- Performing Test HAVE_STEADY_CLOCK
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/wink/prgs/llvm/llvm-project/build

OK, I'll do that tomorrow.

I disagree but I'm the neophyte :)

A few suggestions to consider, but this is GREAT, thanks!

In D62033#1505748, @beanz wrote:

I don't know that we want to support building component libraries as both STATIC and SHARED except in very specific and limited situations.

We actually don't seem to use this functionality in-tree anywhere, so I'm more inclined to turn this into an error than to fix it.

In D62033#1505561, @beanz wrote:

Why are the clang libraries being built STATIC and SHARED?

We need to understand the problem you are trying to solve, because this doesn't seem like the right solution.

Is there anything more I need to do to get this merged?

I believe this is ready for merging, is there something more I need to do?

Just to be clear, I have nothing to do with any distribution except as a user (Arch Linux) so please take
what I say and request with a huge grain of salt. As mentioned I have filed a bug
against the clang package in Arch Linux so hopefully we'll be able to get them going in the right direction.

In D61909#1505046, @beanz wrote:

There is a simpler example distribution configuration, but sadly there isn't documentation. That is something I can fix.

Distributions only get libclang_shared if they run the install target which installs all of LLVM & Clang. The point of LLVM_DISTRIBUTION_COMPONENTS is to allow people constructing distributions to choose which pieces they want to install without introducing a whole lot of overhead in the build system. The old method of passing dozens of flags to enable and disable individual pieces of the build resulted in a combinatoric explosion in build settings which are confusing and ill understood. The new method is one setting that is much cleaner to use.

Anyone constructing a distribution should be specifying LLVM_DISTRIBUTION_COMPONENTS and running the install-distribution target.

In D61909#1503483, @beanz wrote:

In D61909#1503433, @winksaville wrote:

IMHO "BUILD_CLANG_DYLIB" is needed. As you have it now libclang_shared.so is always builds on UNIX systems, which I believe means that all linux distros would have both increasing their sizes.

Distributions shouldn't be installing all unless they really want everything and the kitchen sink. We have the LLVM_DISTRIBUTION_COMPONENTS so that distributions can decide which pieces of the LLVM & Clang distributions they want to install. That is the cleanest mechanism for curating an install.

IMHO "BUILD_CLANG_DYLIB" is needed. As you have it now libclang_shared.so is always builds on UNIX systems, which I believe means that all linux distros would have both increasing their sizes. I think the default should be "always" build libclang*.a as it is now, and optionally build libclang_shared.so using some flag.

Abandoning, @beanz has proposed a better solution, D61909

Sorry, the two previous comments were meant for D61909 and I've moved them.

• Should we only build libclang_shared.so if LLVM_BUILD_LLVM_DYLIB is ON?
• Should we use link clang-9 to libclang_shared.so when LLVM_LINK_LLVM_DYLIB is ON?
• Or maybe we should define BUILD_CLANG_DYLIB and LINK_CLANG_DYLIB or ... ?

I did some quick testing.

You mention that you're using OBJECT libraries so objects aren't built mutliples times
and in my current tests the number of steps increased by only 3, it went from 4353 to 4356,
when using this patch, which is great!

@beanz I found what I think is the reason libclang_shared.so isn't being created.

In D61804#1500445, @winksaville wrote:

In D61804#1500409, @beanz wrote:

My change should not have decreased build time from trunk, nor should it have reduced the number of build steps. That patch should generate lib/libClang_shared.so, which will export the C++ API. libClang is unchanged since changing it would break existing clients of the library.

OK, I'll look into what I've done wrong. If you see anything or have any guesses please let me know.

In D61804#1500409, @beanz wrote:

My change should not have decreased build time from trunk, nor should it have reduced the number of build steps. That patch should generate lib/libClang_shared.so, which will export the C++ API. libClang is unchanged since changing it would break existing clients of the library.

Arch Linux is in an unsupported state, and your patch isn't the way forward.

Change default to be CLANG_ENABLE_STATIC_LIBRARIES=ON CLANG_ENABLE_SHARED_LIBRARIeS=OFF

In D61804#1499267, @beanz wrote:

As an additional note, Arch linux should not be building clang with BUILD_SHARED_LIBS nor should it be distributing those ,so files. That isn't a supported configuration for Clang deployment.

In D61804#1499259, @beanz wrote:

I question the general utility of this patch, and I don't really think this does anything we want the build system doing.

Update as suggested by jyknight

Are there any other edits people would like?

I believe this is ready to merge.

Adding action "Accept Revision", I'm not sure this is the processes so correct me if this is inapprporpriate and let me know what I should do.

Supercedded by D61337

LGTM

In D61337#1488898, @eugenis wrote:

Should this be an error and cause an "unsupported configuration"?

But we don't really know that, because a change that makes this configuration supported needs to be in libc or in platform build files, not in compiler-rt. I'd rather not block anyone from experimenting.

What about makeing it a warning, "untested configuration"? Obviously your call, just seems prudent to me.

Sorry, but I don't like it for the same reason.

In D61337#1488735, @eugenis wrote:

In D61337#1487120, @winksaville wrote:

@eugenis, which of the following conditions have tests?

HWASAN_WITH_INTERCEPTORS=OFF, SANITIZER_ANDROID=OFF

This configuration does not exist.

Should this be an error and cause an "unsupported configuration"?

But we don't really know that, because a change that makes this configuration supported needs to be in libc or in platform build files, not in compiler-rt. I'd rather not block anyone from experimenting.

@eugenis, which of the following conditions have tests?

HWASAN_WITH_INTERCEPTORS=OFF, SANITIZER_ANDROID=OFF

This configuration does not exist.

@eugenis, which of the following conditions have tests?

Changes suggested by Don Hinton

Apply changes from review comments

Update with additional information

In D61203#1480771, @eugenis wrote:

I think __hwasan_tls should be defined if !SANITIZER_ANDROID, without the other condition.