<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 3:29 PM Ben Craig <<a href="mailto:ben.craig@ni.com">ben.craig@ni.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="word-wrap:break-word">
<div class="gmail-m_4113921704298867666WordSection1">
<p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Those guarantees don't change.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Louis</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="word-wrap:break-word"><div class="gmail-m_4113921704298867666WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Louis Dionne <<a href="mailto:ldionne.2@gmail.com" target="_blank">ldionne.2@gmail.com</a>> <br>
<b>Sent:</b> Monday, March 1, 2021 2:24 PM<br>
<b>To:</b> Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>><br>
<b>Cc:</b> Ben Craig <<a href="mailto:ben.craig@ni.com" target="_blank">ben.craig@ni.com</a>>; Michael Schellenberger Costa <<a href="mailto:mschellenbergercosta@googlemail.com" target="_blank">mschellenbergercosta@googlemail.com</a>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [llvm-dev] [libcxx-dev] Compiler support in libc++<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 1, 2021 at 2:40 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What isn't clear to me is the difference between "building libcxx" and "using the installed here in client code"?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If we ship libc++ on a system, what is the restriction on the system for someone to build a c++ application?<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif">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++.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif">Louis<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Mehdi<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 1, 2021 at 11:01 AM Ben Craig via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">+1 on the compiler support.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I’d love to see a more clearly defined policy for other aspects as well, like supported C libraries and supported OSes.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> libcxx-dev <<a href="mailto:libcxx-dev-bounces@lists.llvm.org" target="_blank">libcxx-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Michael Schellenberger Costa via libcxx-dev<br>
<b>Sent:</b> Monday, March 1, 2021 12:13 PM<br>
<b>To:</b> Louis Dionne <<a href="mailto:ldionne.2@gmail.com" target="_blank">ldionne.2@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Libc++ Dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [libcxx-dev] Compiler support in libc++<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">As a (rare) stl contributor I am also strongly in favor of the proposal.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I greatly reduces the maintenance burden for us.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--Michael <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Am Mo., 1. März 2021 um 18:40 Uhr schrieb Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>>:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">Dear LLVM community,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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++.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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:</span><u></u><u></u></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">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.</span><u></u><u></u></li><li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">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.</span><u></u><u></u></li><li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">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.</span><u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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:</span><u></u><u></u></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">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.</span><u></u><u></u></li><li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">We support the latest major release of GCC, as advertised on
<a href="https://urldefense.com/v3/__https:/gcc.gnu.org/releases.html__;!!FbZ0ZwI3Qg!_y_XK6BpuoqsamYVQvCUSV4xy-Iu4uA2X5phLfQkA8xyHl-u4Jzu191vT6ko$" target="_blank">
https://gcc.gnu.org/releases.html</a>.</span><u></u><u></u></li><li class="MsoNormal" style="color:black;vertical-align:baseline;font-variant-ligatures:normal;font-variant-east-asian:normal;white-space:pre-wrap">
<span style="font-family:Arial,sans-serif">We support the latest major release of AppleClang.</span><u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">Thanks,</span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">Louis</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> </span><u></u><u></u></p>
<p style="margin:0in"><span style="font-family:Arial,sans-serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Arial,sans-serif"> </span><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev__;!!FbZ0ZwI3Qg!_y_XK6BpuoqsamYVQvCUSV4xy-Iu4uA2X5phLfQkA8xyHl-u4Jzu11KtVEpS$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!FbZ0ZwI3Qg!7MVuRkw8V868UV40HvsdcVRNofw4JL2ub_Hi--6ViDVROsC_qp2bcmz8BTMV$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div>