homebrew and llvm 10 packages in apt.llvm.org are broken with undefined reference to getPollyPluginInfo
heidezomp opened this issue · 34 comments
Building with the shiny new llvm10 fails:
[ 98%] Linking CXX executable zig0
/usr/lib/llvm-10/lib/libclangCodeGen.a(BackendUtil.cpp.o): In function `(anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >)':
BackendUtil.cpp:(.text._ZN12_GLOBAL__N_118EmitAssemblyHelper30EmitAssemblyWithNewPassManagerEN5clang13BackendActionESt10unique_ptrIN4llvm17raw_pwrite_streamESt14default_deleteIS5_EE+0x16df): undefined reference to `getPollyPluginInfo()'
collect2: error: ld returned 1 exit status
CMakeFiles/zig0.dir/build.make:163: recipe for target 'zig0' failed
I have installed llvm10 from the official apt repository:
deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 main
Might this be a problem with my installation?
It's a problem with apt.llvm.org. They're aware and will hopefully fix it soon. In the meantime, you'll have to use the same workaround that the CI uses, or build llvm+clang+lld 10 from source.
I am having the same issue with an attempt to combine this LLVM 10 (release) PR in Nixpkgs NixOS/nixpkgs#83350 and the following change to zig's derivation:
diff --git a/pkgs/development/compilers/zig/default.nix b/pkgs/development/compilers/zig/default.nix
index 961e28da82e..ab43c862227 100644
--- a/pkgs/development/compilers/zig/default.nix
+++ b/pkgs/development/compilers/zig/default.nix
@@ -1,18 +1,18 @@
{ stdenv, fetchFromGitHub, cmake, llvmPackages, libxml2, zlib }:
stdenv.mkDerivation rec {
- version = "0.5.0";
+ version = "0d43543";
pname = "zig";
src = fetchFromGitHub {
owner = "ziglang";
repo = pname;
rev = version;
- sha256 = "0xyl0riakh6kwb3yvxihb451kqs4ai4q0aygqygnlb2rlr1dn1zb";
+ sha256 = "144igsf104dlwf8rvxg0dk6brlv73ywhq35r5nnljra81h52wzf9";
};
nativeBuildInputs = [ cmake ];
- buildInputs = [ llvmPackages.clang-unwrapped llvmPackages.llvm libxml2 zlib ];
+ buildInputs = [ llvmPackages.clang-unwrapped llvmPackages.llvm llvmPackages.lld libxml2 zlib ];
preBuild = ''
export HOME=$TMPDIR;
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 30bc0af360e..f0ab0586955 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -15147,7 +15147,7 @@ in
zmqpp = callPackage ../development/libraries/zmqpp { };
zig = callPackage ../development/compilers/zig {
- llvmPackages = llvmPackages_9;
+ llvmPackages = llvmPackages_10;
};
zimlib = callPackage ../development/libraries/zimlib { };I was able to devise a quick-and-dirty workaround to make it possible to build master with Nixpkgs (with NixOS/nixpkgs#83350 merged)
diff --git a/pkgs/development/compilers/zig/default.nix b/pkgs/development/compilers/zig/default.nix
index 961e28da82e..ed521a0e70a 100644
--- a/pkgs/development/compilers/zig/default.nix
+++ b/pkgs/development/compilers/zig/default.nix
@@ -1,18 +1,25 @@
{ stdenv, fetchFromGitHub, cmake, llvmPackages, libxml2, zlib }:
stdenv.mkDerivation rec {
- version = "0.5.0";
+ version = "547ba8eb203fa84d207eb38d8d64c0f7f3162101";
pname = "zig";
src = fetchFromGitHub {
owner = "ziglang";
repo = pname;
rev = version;
- sha256 = "0xyl0riakh6kwb3yvxihb451kqs4ai4q0aygqygnlb2rlr1dn1zb";
+ sha256 = "1qvaky2h4j0bss7qjcwiz7q3jhrwlhbjyjgg91zjp9rz5sx2a24k";
};
nativeBuildInputs = [ cmake ];
- buildInputs = [ llvmPackages.clang-unwrapped llvmPackages.llvm libxml2 zlib ];
+ buildInputs = [ llvmPackages.clang-unwrapped llvmPackages.llvm llvmPackages.lld libxml2 zlib ];
+
+ patches = [ ./llvm10_poly.patch ] ;
+
+ postPatch = ''
+ export llvm_extras=-Wl,${llvmPackages.llvm}/lib/LLVMPolly.so
+ substituteAllInPlace CMakeLists.txt
+ '';
preBuild = ''
export HOME=$TMPDIR;
diff --git a/pkgs/development/compilers/zig/llvm10_poly.patch b/pkgs/development/compilers/zig/llvm10_poly.patch
new file mode 100644
index 00000000000..873c825dfbc
--- /dev/null
+++ b/pkgs/development/compilers/zig/llvm10_poly.patch
@@ -0,0 +1,10 @@
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 97608cddf..e451c0711 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -369,6 +369,7 @@ target_link_libraries(zig_cpp LINK_PUBLIC
+ ${CLANG_LIBRARIES}
+ ${LLD_LIBRARIES}
+ ${LLVM_LIBRARIES}
++ @llvm_extras@
+ )
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 30bc0af360e..f0ab0586955 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -15147,7 +15147,7 @@ in
zmqpp = callPackage ../development/libraries/zmqpp { };
zig = callPackage ../development/compilers/zig {
- llvmPackages = llvmPackages_9;
+ llvmPackages = llvmPackages_10;
};
zimlib = callPackage ../development/libraries/zimlib { };I run into the same problem installing zig --HEAD from homebrew on macos:
$ brew install zig --HEAD
Updating Homebrew...
==> Cloning https://github.com/ziglang/zig.git
Cloning into '/Users/josephg/Library/Caches/Homebrew/zig--git'...
Updating files: 100% (9367/9367), done.
==> Checking out branch master
Already on 'master'
Your branch is up to date with 'origin/master'.
==> cmake .
==> make install
Last 15 lines from /Users/josephg/Library/Logs/Homebrew/zig/02.make:
[ 98%] Building CXX object CMakeFiles/zig0.dir/src/stage2.cpp.o
/usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang++ -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/zig0.dir/src/main.cpp.o CMakeFiles/zig0.dir/src/stage2.cpp.o -o zig0 [...]
Undefined symbols for architecture x86_64:
"getPollyPluginInfo()", referenced from:
(anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) in libclangCodeGen.a(BackendUtil.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [zig0] Error 1
make[1]: *** [CMakeFiles/zig0.dir/all] Error 2
make: *** [all] Error 2
Homebrew fix: Homebrew/homebrew-core#52352
LLVM 10 release is in Nixpkgs now NixOS/nixpkgs#83350
:/ That homebrew fix didn't work (see the issue), and adding "-Wl,/usr/local/opt/llvm/lib/libPolly.so" gives me this error:
$ make
Configuring zig version 0.5.0+f6d384450
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/josephg/3rdparty/zig/build
[ 76%] Built target embedded_softfloat
[ 80%] Built target zig_cpp
[ 82%] Built target opt_c_util
[ 97%] Built target zigcompiler
[ 98%] Linking CXX executable zig0
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/usr/local/opt/llvm/lib/LLVMPolly.so' for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [zig0] Error 1
make[1]: *** [CMakeFiles/zig0.dir/all] Error 2
make: *** [all] Error 2
EDIT
Linking to all the static versions of the library worked. In CMakeLists.txt:
target_link_libraries(zig_cpp LINK_PUBLIC
${CLANG_LIBRARIES}
${LLD_LIBRARIES}
${LLVM_LIBRARIES}
"-Wl,/usr/local/opt/llvm/lib/libPolly.a"
"-Wl,/usr/local/opt/llvm/lib/libPollyPPCG.a"
"-Wl,/usr/local/opt/llvm/lib/libPollyISL.a"
)@josephg
Thank you so much! It has been frustrating waiting for the Homebrew team to fix the issue. I was making do with the latest binary from master. This should work nicely till that issue is fixed upstream. Cheers!
I've been asked a few times about this over at Homebrew from people coming over from here. Just to make everyone aware, this is a comment I made on the matter before: Homebrew/homebrew-core#52352 (comment) (after the bullet points).
I've looked at the issue more since then, so let me clarify a few things:
- This is not specific to Homebrew or apt.llvm.org.
- LLVM links Polly into Clang libraries by default. This is not a "misconfiguration". It is intentional.
- As such, Polly is a required dependency of clangCodeGen when Polly is built. If you link clangCodeGen you must link Polly.
To answer some questions I've been asked:
Why does Polly not automatically get linked when you link clangCodeGen?
Because clangCodeGen is a static library. This is an inherent attribute of static libraries.
Why does zig not detect to link Polly itself?
Because zig provides a manual list of what to link when it comes to Clang:
Lines 37 to 58 in a20f3e3
How do you detect whether Polly should be linked?
Let CMake handle the linking work for you and use Clang's provided CMake modules. They can be found in <LLVM prefix>/lib/cmake/clang.
It handles what should be linked. For example, lib/cmake/clang/ClangTargets.cmake provides a target called clangCodeGen lists Polly in its INTERFACE_LINK_LIBRARIES:
# Create imported target clangCodeGen
add_library(clangCodeGen STATIC IMPORTED)
set_target_properties(clangCodeGen PROPERTIES
INTERFACE_LINK_LIBRARIES "clangAnalysis;clangAST;clangASTMatchers;clangBasic;clangFrontend;clangLex;clangSerialization;LLVM;Polly"
)
There is a ClangConfig.cmake to allow the above to be used after a find_package - don't include the file directly.
A similar system for LLVM libraries also exists.
Is there another way?
Use the clang-cpp shared library instead of static libraries. Shared libraries avoid a lot of problems that static libraries have. There is a clang-cpp target in the CMake files too so you can combine the two solutions.
There's a big move in some of the community to stop using Clang static libraries and start using clang-cpp. For example, over at Fedora: https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component-Libraries-In-clang-lib-Package. Fedora plan to remove Clang static libraries from the clang-libs package in Fedora 32.
What about llvm-config?
llvm-config is not for Clang libraries.
I strongly discourage using llvm-config. It is known to be buggy (borderline broken in fact) on macOS, and is not maintained very much upstream. Upstream strongly dissuades its use inside CMake as the CMake modules are much superior: https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/CMakeLists.txt#L17-L21
Thanks for the clarification @Bo98. It's a bit of a problem that LLVM forces downstream projects to use cmake in order to properly link against it, but that's not Homebrew's fault. I'm looking into this and will attempt to make zig's cmake configuration compatible with Homebrew, and stop sending people your way. Thanks again for stopping by.
It's a bit of a problem that LLVM forces downstream projects
Yeah, it caught out Mesa too I heard.
They don't use CMake, so they had to go with the clang-cpp shared library option: https://github.com/mesa3d/mesa/commit/ff1a3a00cb37d84ab9a563f0aa241714876f56b4.
I've opened #4992 to solve this. Now it's just the O(N) task of testing it on all the various systems and putting in workarounds to fix the breakage.
@Bo98 I tried taking your advice and going full cmake-based configuration. That work is in #4992. It successfully built against the Homebrew package.
However, the apt.llvm.org packaging problem persists (and is reproduced by an LLVM dev), and there are other show-stopping problems with cmake-based config.
So I've made the much less invasive change: #4993
This also solved building against Homebrew on my macOS laptop, and I expect the CI tests to pass. So unless you have any objections, this is what you're going to see with the 0.6.0 release on Monday.
I'm not aware of any other patches or issues downstream, but please let me know and I would be happy to work with you on getting that patch count (and other unwanted workarounds) down to zero.
I'm sorry, I'm going to have to push back on this a little bit. I pushed e857190 because #4993 broke the build from building llvm and clang from source.
Building from source (with default llvm and clang cmake options) caused:
CommandLine Error: Option 'mc-relax-all' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
Due to llvm static libraries being linked twice, once in libclang-cpp.so and once again directly. This plus C++ static initializers results in the problem.
I also tried not including llvm static libraries on the linker line (note that there is no libLLVM.so by default when compiling from source), and this caused undefined reference linker errors.
My hands are tied. I really tried to do this the "right" way, the way everybody upstream/downstream wants me to, but it doesn't work.
So homebrew users will have to pass -DZIG_PREFER_CLANG_CPP_DYLIB=ON to cmake. I hope that can be resolved, but this will require LLVM and Clang to get their acts together.
Here's a related IRC conversation log, for posterity.
<andrewrk> hi, I'm switching zig to use ClangConfig.cmake and LLVMConfig.cmake instead of llvm-config. What's the best way to make cmake find llvm 10's files instead of 9? https://clbin.com/zN2uH
<andrewrk> this system used apt.llvm.org to install llvm and clang 10 but cmake is finding the system's 9 cmake files
<andrewrk> I'm about ready to slap a `sudo rm -rf /usr/lib/llvm-9` in the CI script
<nicolas17> both versions are in /usr?
<andrewrk> this is ubuntu bionic
<nicolas17> I mean, v10 isn't self-built and in a different directory?
<andrewrk> you're asking what apt.llvm.org does?
<nicolas17> ah apt.llvm
<nicolas17> yeah I checked and that installs in the usual places
<andrewrk> not trying to dodge your question, I'm attempting to reproduce in a docker container since I can't ssh into the CI system
<nicolas17> what does your find_package look like?
<andrewrk> ok, I can't repro in a docker container. this appears to be azure installing a bunch of garbage :-/
<andrewrk> https://github.com/ziglang/zig/pull/4992/files
<andrewrk> oh my god they even put llvm-8 on this box
<andrewrk> next question: is there an extra step to get the cmake files into the path? https://clbin.com/dA3t4
<andrewrk> I thought apt.llvm.org would automatically install the cmake files
<nicolas17> I'm looking into it, it looks like clang-9 from ubuntu repos and clang-10 from apt.llvm.org are installing files in the same places (except s/9/10/), so it should be working :/
<nicolas17> did you install clang-10?
<nicolas17> the ClangConfig file is installed by that, not by the lib* packages
<nicolas17> not sure if that makes sense...
<andrewrk> yes, the script is here: https://github.com/ziglang/zig/blob/rework-cmake-llvm-config/ci/azure/linux_script#L18
<andrewrk> oh, I see, ok I'll try that
<andrewrk> thanks I would not have figured that out
<nicolas17> yeah I would expect libclang-10-dev to install that but it doesn't seem to be the case
<andrewrk> ok testing that change. while I have you on the line, here's another problem, different ci system: https://clbin.com/izd69 this is happening because I'm trying to keep the docker image small: https://github.com/ziglang/docker-zig/blob/ccffc9ab67bd7024eca340ea066710c2d644ef40/Dockerfile#L63
<andrewrk> here I only copied llvm-config, plus the include/ and lib/ files over
<andrewrk> but now with the cmake based configure approach it wants me to have unnecessary binary files installed
<andrewrk> the docker image is already ~600 MiB. is there something I can do to get around this?
<nicolas17> if you install libclang-10-dev alone, you get .a static libraries to link to but no cmake config file; if you install clang-10 alone, you get the config file that references .a files that aren't present... what the heck is this
<andrewrk> idk, but I'm in a pinch, because I'm getting pressure from homebrew to switch from the way I would prefer to do it, which is using normal posix prefix paths: https://github.com/ziglang/zig/issues/4799#issuecomment-611794872
<andrewrk> this is related to https://bugs.llvm.org/show_bug.cgi?id=44870
<andrewrk> WTF? "make[2]: *** No rule to make target '/usr/lib/llvm-10/lib/libPolly.a', needed by 'zig0'. Stop."
<nicolas17> re: https://clbin.com/izd69, yeah looks like the cmake config for llvm references every target (both binaries and libraries) and doesn't like it if either is missing :/
<nicolas17> with the apt packages: installing clang-10 and libclang-10-dev with apt recommends disabled, I get "LLVMConfig.cmake not found"
<nicolas17> installing llvm-10-dev (which is a Recommends so it's usually installed by default) lets it all work, because it hard-depends on llvm-10-tools so stuff like llvm-tblgen will be present too
<andrewrk> with https://github.com/ziglang/zig/blob/99ba329d56b1f11c769ecf20fde0ed5717475266/ci/azure/linux_script#L18 I'm getting "make[2]: *** No rule to make target '/usr/lib/llvm-10/lib/libPolly.a'
<andrewrk> here's the relevant cmake lines: https://github.com/ziglang/zig/blob/99ba329d56b1f11c769ecf20fde0ed5717475266/CMakeLists.txt#L66-L94
<nicolas17> ah, I'm not because I'm not linking to anything yet :P (my CMakeLists is literally just the find_package)
<nicolas17> yep, can reproduce...
<nicolas17> and is polly even packaged? :/
<andrewrk> I might go back to claiming this is an upstream issue
<nicolas17> the immediate bug here is in the packaging
<nicolas17> if they're going to build llvm with polly support... llvm-10-dev needs to include libPolly.a
<andrewrk> agreed
<nicolas17> I just got the package sources
<nicolas17> polly isn't referenced in any debian/*.install file
<andrewrk> why is polly even a separate thing? I don't understand why it can't just be a normal library like the rest of the llvm libraries
<nicolas17> that comment in issue 4799 basically says "you're not passing libPolly to the linker, if you used clang's cmake modules it would do that automatically", but then you get the problem that libPolly.a doesn't *exist* in the apt packages :/
<nicolas17> I don't even have a clear idea of what polly *is* so I can't answer why it's a "separate thing" ^^
<nicolas17> but llvm-10-dev.install says include all libLLVM*.a, libLTO.* and libRemarks.* in the package
<nicolas17> libRemarks is also missing the "LLVM" prefix so you could say it's as weird as libPolly, it's just the package accounts for that difference
<andrewrk> I see
<andrewrk> even if that is fixed, I still have the docker image problem, with the cmake config approach
<andrewrk> unless there is some way to adjust the docker file so that I don't need any bin/* files
* ChanServ gives channel operator status to jdoerfert
<andrewrk> it seems like that code in the cmake config is trying to be helpful by pointing out the installation is borked but it's only getting in the way, maybe it can simply be deleted
<andrewrk> ^ re: https://clbin.com/izd69
<nicolas17> maybe that could be improved so that if the binaries aren't installed, it doesn't define those targets, instead of erroring out
<andrewrk> that would make me happy
<andrewrk> and you would have one less downstream user of llvm-config
However, the apt.llvm.org packaging problem persists (and is reproduced by an LLVM dev), and there are other show-stopping problems with cmake-based config.
I'm sorry to hear that.
In regards to #4992, it might not be using clang-cpp as you intended. CLANG_LINK_CLANG_DYLIB doesn't appear in the config files in my install. It seems like it just relies on LLVM_LINK_LLVM_DYLIB. This is fine though as CLANG_LINK_CLANG_DYLIB really just tells whether the Clang executables are linked with libclang-cpp which you probably don't care about. LLVM_LINK_LLVM_DYLIB will tell you that libclang-cpp is linked to libLLVM. It also sort of shows libLLVM exists (it is possible that it can exist while LLVM_LINK_LLVM_DYLIB is OFF but that's probably not worth worrying about - particularly since linking a clang-cpp that used LLVM static libraries doesn't really work well as you noticed).
You're right that apt.llvm.org does not appear to include the Polly static library. As such, building using the clangCodeGen static library is impossible with apt.llvm.org and only clang-cpp will work there.
Due to llvm static libraries being linked twice, once in libclang-cpp.so and once again directly.
Ah, that makes sense. If the CMake solution worked, LLVM_LINK_LLVM_DYLIB would have checked for this.
So homebrew users will have to pass -DZIG_PREFER_CLANG_CPP_DYLIB=ON to cmake.
Sure, I can change the formula to do that.
The ball is back in LLVM/Homebrew's court. #5055 (comment)
Homebrew + LLVM have put us in an impossible situation
I might be wrong, but I'm guessing this is also why I'm encountering the following issue on Ubuntu?
brew install --HEAD zig
[...]
bin/ld: cannot find /usr/local/opt/llvm/lib/libPolly.a: No such file or directory
bin/ld: cannot find /usr/local/opt/llvm/lib/libPollyPPCG.a: No such file or directory
bin/ld: cannot find /usr/local/opt/llvm/lib/libPollyISL.a: No such file or directory
Does this mean that we will have to wait for llvm to fix it in their next major release? Also, having read the relevant threads, will it still be possible to get a working build if I build clang+lld from source? I've been stuck at the last working revision (448f8c2eb8335e1c8fc0dd76c3ed728b80487a63) for some time now. :-)
As for the apt.llvm.org packages, I just got an update of llvm-toolchain-10 (1:10.0.1~++20200626113502+77d76b71d7d-1~exp1~20200626214123.189) that seems to fix linking to Polly; manually adding "-Wl,/usr/lib/llvm-10/lib/LLVMPolly.so" to the libraries in CMakeLists.txt isn't required anymore and a clean checkout/build of Zig now builds and runs fine on my system.
Thank's @andrewrk , cmake -DZIG_WORKAROUND_POLLY_SO:STRING=/usr/lib/llvm-10/lib/LLVMPolly.so ..
Worked also for me on ubuntu 20.04 LTS
EDIT: Never mind, it works using the macOS-specific workaround flag.
Doesn't work on macOS 10.15.4 using LLVM 10.0.0:
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/usr/local/opt/llvm/lib/LLVMPolly.so' for architecture x86_64
Works for me with LLVM 10.0.1 on MacOS
I'm getting a new and different error on the new (10.0.1) homebrew release of LLVM :D
ld: library not found for -llibxml2.tbd
I'm getting a new and different error on the new (
10.0.1) homebrew release of LLVM :Dld: library not found for -llibxml2.tbd
I can confirm that this is indeed the problem with llvm-config. In particular, it comes from running:
$ llvm-config --system-libs
> -lz -lcurses -lm -llibxml2.tbd
😢
A temporary (and super hacky hack hack that makes me cringe) solution to the problem of
ld: library not found for -llibxml2.tbd
is to:
- Create a symbolic link
/usr/local/lib/liblibxml2.tbd.dylib -> /usr/lib/libxml2.2.dylib - Add
/usr/local/libto your dyld search path if it's not already there. The easiest way is to simply addLINK_FLAGS "-L/usr/local/lib"tozig0andzigtarget properties inCMakeLists.txt:
set_target_properties(zig0 PROPERTIES
COMPILE_FLAGS ${EXE_CFLAGS}
LINK_FLAGS ${EXE_LDFLAGS}
LINK_FLAGS "-L/usr/local/lib"
)
This should get everyone with LLVM 10.0.1 installed via Homebrew on macOS going for now.
I think we can mark this particular issue as resolved (to do with polly), and unfortunately, instead, open a new issue to do with the latest error:
ld: library not found for -llibxml2.tbd
which also seems an upstream issue...
EDIT: I've now created an issue for this #6087.
LLVM 11 was released today and I just merged the llvm11 branch into master.
LLVM 11 was released today and I just merged the llvm11 branch into master.
Just a heads up that at the time of writing, homebrew still doesn't feature LLVM updated to version 11, so anyone developing on a macOS might either wait a little, or install LLVM from source.
Or use the bootstrap repository.
Just an FYI that I'm working hard on updating LLVM to 11 in homebrew in Homebrew/homebrew-core#62798
Note for future readers: this one got merged, so brew install llvm and then cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix llvm) from your build directory and you're good to go! You may need to remove an old CMakeCache.txt.