[libcxx-commits] [PATCH] D74489: [libc++] Remove workarounds for the lack of clock_gettime on older macOS platforms

Wed Jan 20 13:51:41 PST 2021

rnk added a comment.

In D74489#2505156 <https://reviews.llvm.org/D74489#2505156>, @ldionne wrote:

> In D74489#2497044 <https://reviews.llvm.org/D74489#2497044>, @thakis wrote:
>
>> We're looking into bumping libc++ in chromium, and this is a problem for us. We statically link libc++, and we still support 10.11. (We _just_ dropped support for 10.10 in our last release iirc.) What do you recommend as path forward?
>
> Ugh, that's unfortunate. I see two options:
>
> 1. We revert the patch here, or
> 2. You carry a local patch until you don't support 10.11 anymore

I would prefer a revert if possible, since we are currently using a mirror of libc++ and don't have a good way to carry a local patch. We could create one if necessary, but it's work that will hopefully become obsolete in another year.

> The underlying question I'm really curious to hear the answer to is why don't you use the system `libc++.dylib`? How do you make sure that you don't have ODR issues when linking against macOS system frameworks that might be linking against `libc++.dylib`?

I believe Chrome statically links its own libc++, uses the unstable ABI, and disables the libc++ visibility annotations. So, all our libc++ symbols should be hidden, and should not conflict with the dylib symbols. I see some evidence in the build files that people have run into ODR issues in the past and have worked around them by doing things like `-D_LIBCPP_ABI_VERSION=Cr` in certain configurations.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74489/new/

https://reviews.llvm.org/D74489