Date: Thu, 18 Jul 2024 16:15:22 -0700
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.
> 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
Received on 2024-07-18 23:15:30