[lldb] Link LLDB only against libclang and libLLVM .a files to fix macOS build

[kubamracek]

Summary

The Xcode macOS build of LLDB is currently broken after https://reviews.llvm.org/D23232 landed, see http://lab.llvm.org:8080/green/job/lldb_build_test/20014/console, because we’re trying to link against all .a files found in the llvm-build/lib directory. Let’s be more specific in what we link against. This patch applies a regexp to only use “libclang.*”, “libLLVM.*” and not “libclang_rt.*” static archives.

[compnerd]

scripts/Xcode/build-llvm.py

138

Why not use llvm-config to get the linker parameters and the correct ordering rather than relying on the alphabetical ordering (linker options are order dependent, more so in some object formats than others) and hoping that patterns will do the trick? In particular, the --libs option and --component options are interesting. If you really want to use the full path, you can abuse the --libfiles option in llvm-config.

[kubamracek]

scripts/Xcode/build-llvm.py

138

Good point. Is there a way to get a list of _Clang_ static libraries?

[compnerd]

scripts/Xcode/build-llvm.py

138

I dont *think* that there is. In general, clang isn't as modular as LLVM and doesn't provide components to embed it into other uses :-(. I suspect that its best to empirically work out the current dependency (start with -lclangBaisc -lclangCodeGen and add dependencies as necessary). Im basing the beginning point on what the clang driver links against. If the dependencies for the library change, it should be pretty quick to spot the breakage. With more components trying to re-use clang (lldb was the first, swift is the new kid on the block), I think it may make some sense to provide a clang-config tool, but that would be a much longer term thing.

[tfiala]

I think we're going to go with this for now. We can improve it later. I'd rather not use separate mechanisms for collecting the llvm and clang libraries.

I don't like the "collect all libs" approach since it can break incremental builds on CI if a library is removed - the old .a will still be around and get collected into the build.

That will require some more investigation, though. This change addresses the broken LLVM.org LLDB Green Dragon macOS builder.

[tfiala]

This change also likely needs to have an adjustment in some downstream repositories (e.g. for Swift).

[tfiala]

I filed the following bugzilla bug to track the idea of making this smarter:
https://llvm.org/bugs/show_bug.cgi?id=28953

[tfiala]

Committed here:
r278527

scripts/Xcode/build-llvm.py

 #!/usr/bin/env python
 
 import errno
 import hashlib
 import fnmatch
 import os
 import platform
+import re
 import subprocess
 import sys
 
 from lldbbuild import *
 
 #### SETTINGS ####
 
 def LLVM_HASH_INCLUDES_DIFFS ():

 def CMAKE_ENVIRONMENT ():
     return {
     }
 
 #### COLLECTING ALL ARCHIVES ####
 
 def collect_archives_in_path (path): 
     files = os.listdir(path)
-    return [os.path.join(path, file) for file in files if file.endswith(".a")]
+    # Only use libclang and libLLVM archives, and exclude libclang_rt
+    regexp = "^lib(clang[^_]|LLVM).*$"
+    return [os.path.join(path, file) for file in files if file.endswith(".a") and re.match(regexp, file)]
 
 def archive_list ():
     paths = library_paths()
     archive_lists = [collect_archives_in_path(path) for path in paths]
     return [archive for archive_list in archive_lists for archive in archive_list]
 
 def write_archives_txt ():
     f = open(archives_txt(), 'w')