llvm dev - Mar 2021 - Compiler support in libc++

On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev
wrote:
> However, for a library like libc++, things are a bit different.
So how does this prevent the libstdc++ mess that you need to lock step
the RTL with the compiler and more importantly, get constantly screwed
over when you need to upgrade or downgrade the compiler in a complex
environment like an actual Operating System?

I consider this proposal a major step backwards...

Joerg

> On Mar 1, 2021, at 15:41, Joerg Sonnenberger via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev wrote:
>> However, for a library like libc++, things are a bit different.
> 
> So how does this prevent the libstdc++ mess that you need to lock step
> the RTL with the compiler and more importantly, get constantly screwed
> over when you need to upgrade or downgrade the compiler in a complex
> environment like an actual Operating System?
Could you please elaborate on what issue you’re thinking about here? As someone
who ships libc++ as part of an operating system and SDK (which isn’t necessarily
in perfect lockstep with the compiler), I don’t see any issues. The guarantee
that you can still use a ~6 months old Clang is specifically intended to allow
for that use case, i.e. shipping libc++ as part of an OS instead of a toolchain.

> I consider this proposal a major step backwards...
To be clear, we only want to make official the level of support that we already
provide in reality. As I explained in my original email, if you’ve been relying
on libc++ working on much older compilers, I would suggest that you stop doing
so because nobody is testing that and we don’t really support it, despite what
the documentation says. So IMO this can’t be a step backwards, since we already
don’t support these compilers, we just pretend that we do.

Louis