After LLVM moved to C++14, the RWMutex implementation was removed in
favor of std::shared_timed_mutex, which is only available on macOS
10.12 and later. As a workaround for older deployment targets, I added
the original RWMutexImpl again, guarded by the deployment target.
When doing a standalone build of LLDB using the Xcode generator, the
CMake cache specifies a minimum deployment target. However, LLVM and
Clang might have been built with a different minimum deployment target.
This is exactly what happened for the Xcode build. LLVM was built with a
minimum deployment target newer than 10.12, using
std::shared_timed_mutex. LLDB on the other hand was built with a minimum
deployment target of 10.11, using the old RWMutexImpl, resulting in
undefined symbols at link-time.
This patch changes the minimum deployment target for the Xcode build to
10.12 to work around this problem. A better solution would involve
synchronizing the minimum deployment or even not setting one at all.
llvm-svn: 369220
Summary:
Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake
```
When building with Xcode, we recommend using the corresponding cache
script. If this was a mistake, clean your build directory and re-run
CMake with:
-C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake
See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject
```
Also set the generator inside the cache script.
Reviewers: JDevlieghere, jingham, clayborg
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65797
llvm-svn: 368066
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship `libc++.dylib` and/or `libc++.a`). Disable the respective link steps to avoid the dependency to libc++abi.
<rdar://problem/51980716>
llvm-svn: 365038
Summary:
CMake cache scripts pre-populate the CMakeCache in a build directory with commonly used settings.
The CMake invocation from D61952 could look like this:
```
cmake -G Ninja -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-osx.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm-project/llvm
```
Options specified on the command line will override options in the cache files (as long as caches don't use `FORCE`).
What do you think? (This is a first proposal and not set in stone.)
Reviewers: xiaobai, compnerd, JDevlieghere, aprantl, labath
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61956
llvm-svn: 361069