Page MenuHomePhabricator

[libc++] Remove workarounds for the lack of clock_gettime on older macOS platforms
ClosedPublic

Authored by ldionne on Feb 12 2020, 8:44 AM.

Details

Summary

This increases the Mac OS requirement for building libc++ to 10.12.
Note that it doesn't change whether the *headers* still support older
platforms -- it's only that macOS >= 10.12 is required to build the
dylib from sources.

Event Timeline

ldionne created this revision.Feb 12 2020, 8:44 AM

Feedback on this change was requested in http://lists.llvm.org/pipermail/libcxx-dev/2020-February/000688.html and nobody objected, so I think we're good to move forward.

@EricWF @mclow.lists Good?

EricWF accepted this revision.Feb 26 2020, 2:00 PM
This revision is now accepted and ready to land.Feb 26 2020, 2:00 PM
ldionne updated this revision to Diff 268910.Jun 5 2020, 12:21 PM

Rebase onto master and update documentation

Herald added a reviewer: Restricted Project. · View Herald TranscriptJun 5 2020, 12:21 PM
Herald added subscribers: jfb, arphaman. · View Herald Transcript
This revision now requires review to proceed.Jun 5 2020, 12:21 PM
ldionne accepted this revision as: Restricted Project.Jun 5 2020, 12:22 PM
This revision is now accepted and ready to land.Jun 5 2020, 12:22 PM
This revision was automatically updated to reflect the committed changes.

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?

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

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?

rnk added a subscriber: rnk.Jan 20 2021, 1:51 PM

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.