[llvm-dev] [libcxx-dev] Compiler support in libc++

Mon Mar 1 12:23:36 PST 2021

On Mon, Mar 1, 2021 at 2:40 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

> Hi,
>
> What isn't clear to me is the difference between "building libcxx" and
> "using the installed here in client code"?
> If we ship libc++ on a system, what is the restriction on the system for
> someone to build a c++ application?
>
The compiler requirements would be the same for building libc++ and for
using its headers to build a client application. So basically, you'd be
required to use a recent compiler when building an application against
recent libc++ headers.

The basic idea is that someone shipping libc++ as part of a toolchain would
update Clang at the same time as they update libc++, and any application
would be built against a combination of that Clang and the matching libc++.
As I said, we'd actually support something more lenient than that, i.e.
libc++ would support up to the last stable release of Clang. That way,
people who don't ship libc++ as part of  a LLVM-based toolchain would have
a 6 month grace period to update their compiler at each release of libc++.

Louis

> Thanks,
>
> --
> Mehdi
>
>
> On Mon, Mar 1, 2021 at 11:01 AM Ben Craig via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> +1 on the compiler support.
>>
>>
>>
>> I’d love to see a more clearly defined policy for other aspects as well,
>> like supported C libraries and supported OSes.
>>
>>
>>
>> *From:* libcxx-dev <libcxx-dev-bounces at lists.llvm.org> * On Behalf Of *Michael
>> Schellenberger Costa via libcxx-dev
>> *Sent:* Monday, March 1, 2021 12:13 PM
>> *To:* Louis Dionne <ldionne.2 at gmail.com>
>> *Cc:* llvm-dev at lists.llvm.org; Libc++ Dev <libcxx-dev at lists.llvm.org>
>> *Subject:* [EXTERNAL] Re: [libcxx-dev] Compiler support in libc++
>>
>>
>>
>> As a (rare) stl contributor I am also strongly in favor of the proposal.
>>
>>
>>
>> I greatly reduces the maintenance burden for us.
>>
>>
>>
>> --Michael
>>
>>
>>
>> Am Mo., 1. März 2021 um 18:40 Uhr schrieb Louis Dionne via libcxx-dev <
>> libcxx-dev at lists.llvm.org>:
>>
>> Dear LLVM community,
>>
>>
>>
>> I’ve wanted to address the topic of which compilers are supported by
>> libc++ for a long time. LLVM documents that it supports GCC >= 5, Clang >=
>> 3.5 and other fairly old compilers. I think this makes a lot of sense for
>> codebases like LLVM and Clang, since it means you can bootstrap a compiler
>> with your system compiler in many cases. It’s also fairly easy to enforce
>> that, since you just have to code in a supported subset of C++.
>>
>>
>>
>> However, for a library like libc++, things are a bit different. By its
>> very nature, libc++ needs to rely on a recent compiler in order to
>> implement most recent library features. Not being able to rely on a recent
>> compiler leads to problems:
>>
>>    - Adding new features is significantly more complicated because we
>>    need to implement them conditionally on compiler support, not just on
>>    support for a C++ Standard. There can also be interactions between what
>>    compiler the library is built with and what compiler the headers are used
>>    with.
>>    - We accumulate technical debt around the code base. Some of these
>>    #ifdef code paths are not in use anymore, others don’t compile anymore or
>>    they contain bugs.
>>    - It creates a false sense of support: people think they can use a
>>    libc++ built with e.g. Clang 3.5, but in reality doing so is a terrible
>>    idea. The library might not contain runtime support for features that will
>>    be advertised as available by the headers (the char8_t RTTI and the
>>    upcoming support for <format> come to mind). Those are serious ABI issues
>>    that you’ll only notice when trying to use the feature.
>>
>>
>>
>> I think it’s important to stress that the current state of things is that
>> we don’t *actually* support much older compilers - the documentation claims
>> we do, but that is misleading. While things may happen to work on older
>> compilers, I wouldn’t recommend relying on that for anything serious, since
>> it’s mostly untested.
>>
>>
>>
>> Furthermore, the actual value of supporting old compilers isn’t obvious.
>> Indeed, the best way of building libc++ is to bootstrap Clang and then
>> build libc++ with it, which is easily achieved with the LLVM Runtimes
>> build. Of course, we also support different shipping mechanisms (including
>> non-Clang compilers), but in all cases it should be reasonable to expect
>> that someone building libc++ at the tip is able to do so using a recent
>> compiler.
>>
>>
>>
>> For all these reasons, I think we must adjust the official support policy
>> we currently document. Concretely, the following modified policy solves the
>> issues I mentioned above and makes it so that the stated support reflects
>> the reality of what we truly support:
>>
>>    - At any given point in time, libc++ supports back to the latest
>>    released version of Clang. For example, if the latest major release of
>>    Clang is 14, libc++ (on main) supports Clang 14. When Clang 15 is released
>>    (and libc++ 15 with it), libc++ (on main) is free to assume Clang 15. As a
>>    result, any released libc++ will always support the previously (and the
>>    currently) released Clang, with the support window moving as newer Clangs
>>    are released.
>>    - We support the latest major release of GCC, as advertised on
>>    https://gcc.gnu.org/releases.html
>>    <https://urldefense.com/v3/__https:/gcc.gnu.org/releases.html__;!!FbZ0ZwI3Qg!_y_XK6BpuoqsamYVQvCUSV4xy-Iu4uA2X5phLfQkA8xyHl-u4Jzu191vT6ko$>
>>    .
>>    - We support the latest major release of AppleClang.
>>
>>
>>
>> The above policy is reasonable from libc++’s perspective, and it also
>> reflects what we test on a regular basis with the CI. Furthermore,
>> supporting up to the last release instead of requiring a trunk compiler
>> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
>> vehicles approximately 6 months to update their compiler if they want to
>> jump on the next release of libc++, which I think is an important property
>> to retain.
>>
>>
>>
>> This message is both a heads up about the current state of things, an
>> explanation of where we (the libc++ contributors) want to end up, and an
>> invitation to have a discussion with the rest of the community.
>>
>>
>>
>> I propose that we maintain our current level of support for older
>> compilers (i.e. keep things roughly building) until the next LLVM release,
>> after which the above policy would become official and libc++ development
>> would be allowed to assume a compiler as documented above. That would give
>> approximately 6 months (from now to the next release) for people managing
>> build bots to migrate to the Runtimes build, and approximately 6 months
>> (from the next release to the next-next release) for external users to
>> adjust to this policy if needed.
>>
>>
>>
>> Thanks,
>>
>> Louis
>>
>>
>>
>> P.S.: There is no mention of other compilers besides Clang, AppleClang
>> and GCC above. That’s because no other compiler is tested on a regular
>> basis, so the status of support for other compilers is unknown. If you’d
>> like to add official support for a new compiler, I’ll be happy to help you
>> set up the required testing.
>>
>>
>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev__;!!FbZ0ZwI3Qg!_y_XK6BpuoqsamYVQvCUSV4xy-Iu4uA2X5phLfQkA8xyHl-u4Jzu11KtVEpS$>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/11d213fd/attachment.html>