clang-tools-extra | Mirror kept for legacy | Compiler library

You should start small with something like a typo to get a feel for the submission and code review process. There is the My First Typo Fix doc for this. Also, watch the How to Contribute to LLVM tutorial from the 2019 Developer Meeting. You will also need reviewers. The LLVM Discord channel, git blame and the LLVM code owners can help here. Lastly, or maybe even firstly, you could post an RFC on the LLVM developers email list.

The static initialization order fiasco, from which you are suffering, occurs when an object in one translation unit may rely on the data from another unit that has not yet been, or is in the process of being, initialized.

Dynamic initialization of static members across translation-units are indeterminately sequenced with respect to all other translation-units. There is no guarantee to the order in which they get initialized, or even if they are on the same thread.

There are a few possible conditions I can think of that may result in you experiencing it while others are not. Factors like hardware, link-order, timing, etc. may all play a role. Some possible cases:

1. Since dynamic-initialization is indeterminately sequenced and not guaranteed to even exist in the same thread, if initialization is multi-threaded on startup, then differing hardware may introduce different initialization timing (race-condition)

2. It could just be that there is a difference in your development environment on your system. Something as small as having a library found in a different location may disrupt the library load-order, which may affect the order in which things are initialized.

3. Assuming your system is performing parallel-compilation, it's possible that your hardware is compiling objects in a different order, which has affected the order these objects get linked in. The link-order may change initialization order -- which may cause you to experience an issue where someone else doesn't.

Ultimately, why you are experiencing this when others are not doesn't actually matter. Formally, you are experiencing undefined behavior, and how it behaves and who it discriminates against cannot be reasoned about.

^{Note: Without a lot more information about your system setup, the best that can be provided is guesswork as to why this is occurring.}

Find the list of targets in the output of ninja help or make help or xcodebuild -list or any other generator.

A project's external name can very well be different from the internal target name.

If you want to build everything, just set the install prefix:

cmake -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" ../llvm -DCMAKE_INSTALL_PREFIX=../my_install

and run make install

It will do the right thing.

Since macOS Catalina, the /usr folder is been mounted as a read-only directory, so even as a root - no one has permission to modify this folder (well, unless you reboot in SIP mode, which's obviously not a considerable solution). The entire toolchain is saved by default under /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk. You can get your path by executing xcrun --show-sdk-path. I'll assume that you do have the default path in my answer but please adjust as needed.

Running clang with the -v flag gave me the following:

You have to specify clang in the LLVM_ENABLE_PROJECTS CMake variable as described in the getting started guide.