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

Mon Mar 1 12:44:34 PST 2021

On Mon, Mar 1, 2021 at 3:29 PM Ben Craig <ben.craig at ni.com> wrote:

> Presumably though, someone building against old headers, but running
> against a new libc++ would still be supported, right?  In other words,
> you’re still going to maintain binary compatibility?
>

Yes, of course. You can always build your application against a version of
libc++ and then link/run it against a newer version of the library (.so or
.dylib). If you specify the right deployment target, you can also build
against a newer version of libc++ (headers and .so/.dylib), and then
actually run it against an older dylib provided your application doesn't
use symbols that didn't exist in the old dylib you're running against.

Those guarantees don't change.

Louis

>
> *From:* Louis Dionne <ldionne.2 at gmail.com>
> *Sent:* Monday, March 1, 2021 2:24 PM
> *To:* Mehdi AMINI <joker.eph at gmail.com>
> *Cc:* Ben Craig <ben.craig at ni.com>; Michael Schellenberger Costa <
> mschellenbergercosta at googlemail.com>; llvm-dev at lists.llvm.org
> *Subject:* [EXTERNAL] Re: [llvm-dev] [libcxx-dev] Compiler support in
> libc++
>
>
>
>
>
>
>
> 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
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!FbZ0ZwI3Qg!7MVuRkw8V868UV40HvsdcVRNofw4JL2ub_Hi--6ViDVROsC_qp2bcmz8BTMV$>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/85b2e910/attachment-0001.html>