[libcxx-commits] [libcxx] 61e8973 - [libc++] Simplify the configuration of the C++ ABI library

[Louis Dionne via libcxx-commits]

> On Apr 2, 2020, at 13:04, Hans Wennborg <hans at chromium.org> wrote:
> 
> On Thu, Apr 2, 2020 at 7:01 PM Louis Dionne <ldionne at apple.com> wrote:
>> 
>> 
>> 
>>> On Apr 2, 2020, at 12:54, Hans Wennborg <hans at chromium.org> wrote:
>>> 
>>> On Thu, Apr 2, 2020 at 8:21 AM Louis Dionne via libcxx-commits
>>> <libcxx-commits at lists.llvm.org> wrote:
>>>> 
>>>> 
>>>> Author: Louis Dionne
>>>> Date: 2020-04-02T02:21:15-04:00
>>>> New Revision: 61e89737c5daf7b65341936f88f68efb680cdcd4
>>>> 
>>>> URL: https://github.com/llvm/llvm-project/commit/61e89737c5daf7b65341936f88f68efb680cdcd4
>>>> DIFF: https://github.com/llvm/llvm-project/commit/61e89737c5daf7b65341936f88f68efb680cdcd4.diff
>>>> 
>>>> LOG: [libc++] Simplify the configuration of the C++ ABI library
>>>> 
>>>> This commit removes support for building against the system libc++abi,
>>>> which was supported on Apple platforms. This is basically never what we
>>>> want to do, since libc++ and libc++abi are coupled and building a trunk
>>>> libc++ against an older libc++abi can lead to incompatibilities (and
>>>> good luck debugging them!). It might have made some sense to support
>>>> that when the monorepo did not exist, however I don't think this is
>>>> anything but a footgun nowadays.
>>>> 
>>>> Furthermore, based on the newly-made assumption that we're building
>>>> against the monorepo libc++abi, we can simplify the search path logic
>>>> for finding libc++abi.
>>>> 
>>>> This area of our build system has a lot of technical debt accumulated,
>>>> and it's surprisingly difficult to change. We've tried different things
>>>> and failed several times in the past. I did test this change on our
>>>> Docker image for the build bots and on Apple platforms, however it is
>>>> possible that this breaks some unknown configuration, in which case it
>>>> should be fine to revert this (so we can try again!).
>>> 
>>> Well hello :-)
>>> 
>>> This broke Chromium's packaging of Clang on Mac (see https://crbug.com/1067216).
>>> 
>>> We build libc++ as part of that process, not because we ship it with
>>> the compiler, but as part of the bootstrapping process: otherwise the
>>> just-built Clang doesn't find the c++ headers. Until now we've been
>>> building with -DLIBCXX_CXX_ABI=libcxxabi -DLIBCXX_CXX_ABI_SYSTEM=1
>>> however with your patch that stopped working.
>>> 
>>> I tried adding libcxxabi to -DLLVM_ENABLE_PROJECTS and dropping those
>>> two flags, but now building libcxxabi failed for unclear reasons
>>> ([1]).
>>> 
>>> Would it be okay to revert your patch until we've figured this out?
>> 
>> We've already applied a couple of patches on top and fixed other failing bots -- we're farther than we've ever been. Any chance of catching you on IM before we revert? I'm trying to repro your failure and I think I'll be able to submit a patch soon (max ~1h).
> 
> I just realized the failure I'm seeing is maybe
> https://bugs.llvm.org/show_bug.cgi?id=42725
> 
> The clang used on that machine is identified by cmake as AppleClang
> 9.0.0.9000037. I'm not entirely sure how to upgrade that, so if you
> have other ideas for how to fix, that would be great.

No, it's not that. I know pretty much exactly what the issue is (I've repro'd), and I'm working on a patch. Once the dust has settled, we'll have to work together to get your libc++ build standardized, though, because LIBCXX_CXX_ABI_SYSTEM is not a publicly tweakable variable for libc++. I think I know what underlying issue you're working around and I think I know the proper fix, which wouldn't require building libc++ at all (since that's not really what you want anyway IIUC).

Louis