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

[Hans Wennborg via libcxx-commits]

On Thu, Apr 2, 2020 at 7:04 PM 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.

Another failure I saw when building locally (I guess my local machine
has a newer xcode) was this:

/work/chromium/src/third_party/llvm/libcxxabi/src/private_typeinfo.cpp:68:19:
error: '~type_info' is unavailable: introduced in macOS 10.9
 __shim_type_info::~__shim_type_info()
                   ^
 /work/chromium/src/third_party/llvm/libcxx/include/typeinfo:285:13:
note: '~type_info' has been explicitly marked unavailable here
     virtual ~type_info();
             ^

I guess that comes from us targeting 10.7.