gecko-dev/build/build-clang/static-llvm-symbolizer.patch
Mike Hommey 42c96ee774 Bug 1492037 - Build clang with LLVM as a shared library. r=froydnj
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.

As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.

With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.

Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).

Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).

Differential Revision: https://phabricator.services.mozilla.com/D6117
2018-09-21 10:41:36 +09:00

13 lines
376 B
Diff

diff --git a/llvm/tools/llvm-symbolizer/CMakeLists.txt b/llvm/tools/llvm-symbolizer/CMakeLists.txt
index 8185c296c50..13c7419fa47 100644
--- a/llvm/tools/llvm-symbolizer/CMakeLists.txt
+++ b/llvm/tools/llvm-symbolizer/CMakeLists.txt
@@ -13,6 +13,7 @@ set(LLVM_LINK_COMPONENTS
)
add_llvm_tool(llvm-symbolizer
+ DISABLE_LLVM_LINK_LLVM_DYLIB
llvm-symbolizer.cpp
)