> std::__cxx11::basic_string
This implies to me the standard library already has a mechanism for
cross-library communication. It just seems it was never properly utilised.
You could extend this to something like
std::ucrt::mingw64::parent_string_class. If you do this for every existing
ABI and then start mandating that vendors put their implementations in said
namespaces for which the standard library can refer to then you can move
std::* stuff away from vendor implementations and instead treat them as
fallbacks for standardised stuff. An example would be that very regex
class. Had this been a thing before you could've from the get go
implemented something like
std::regex::useimplementation(std::libc::clang::regex); and
std::regex::getimplementationname(void);

On Fri, 19 Jul 2024 at 00:15, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday 18 July 2024 15:54:43 GMT-7 Tiago Freire via Std-Proposals
> wrote:
> > While indeed it is a problem changing the ABI of library, that is
> > effectively linked by the binary by explicitly referring to that specific
> > library by name, there is no problem if you change the ABI and put it in
> > library with a different name and have the newer applications use that
> > instead. A compiler could handle that trick for you.
>
> The problem with that is what happens downstream of your library. This was
> what the libstdc++ developers failed to realise or failed to communicate
> when
> they did std::__cxx11::basic_string.
>
> Level 0: libstdc++.so.6 itself
> Entirely compatible with both ABIs
>
> Level 1: content using libstdc++.so.6 directly and little else (or just C)
> Opt-in to each of the ABIs. Once you recompile, you get the new ABI, until
> then the old one still works.
>
> Level 2: content using Level 1
> You don't have a choice. You must use the same one as that library has
> chosen.
> And this applies to every single Level 1 dependency because you can't mix
> and
> match.
>
> You've spoken of having proprietary content that you can't rebuild. That's
> the
> typical example of said Level 1s. But it need not be proprietary only:
> because
> you can't mix and match, all the open source content in the entire system
> must
> go through a flag day to switch from old to new. Linux distributions had
> to do
> a "rebuild world" (or universe) to get through this.
>
> The availability of source is not the only issue either. Sometimes, you
> have
> the source, but it's broken because it was last updated for GCC 4.3. The
> fixes
> may be minimal (missing #includes for the majority), but you incur death
> by
> thousand paper cuts. So this "rebuild the world" is expensive. That's why
> it
> can't happen every year. I'd argue even once a decade is too expensive.
>
> libstdc++ could have gone to .so.7 that day and the cost of updating may
> have
> been exactly the same or nearly so.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>