[llvm-dev] Compiler support in libc++ (original) (raw)
Louis Dionne via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 2 07:10:02 PST 2021
- Previous message: [llvm-dev] Compiler support in libc++
- Next message: [llvm-dev] Compiler support in libc++
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [llvm-dev] Compiler support in libc++
- Next message: [llvm-dev] Compiler support in libc++
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]