Mehdi AMINI via llvm-dev
2021-Mar-01 19:39 UTC
[llvm-dev] [libcxx-dev] Compiler support in libc++
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? 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/2a9222f1/attachment.html>
Louis Dionne via llvm-dev
2021-Mar-01 20:23 UTC
[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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/11d213fd/attachment.html>