[Wheel-builders] C++ ABI v5

[Nathaniel Smith]

Hi Michael,

On Wed, Mar 9, 2016 at 4:33 PM, Michael Sarahan <msarahan at gmail.com> wrote:
> Hi Nathaniel,
>
> Thanks for your feedback.  It sounds like you think this won't be much of an
> issue, and I really hope you're right!  This feels something like the y2k
> bug to me: apocalyptic predictions, but perhaps ultimately little impact.
>
> The issues we have seen to a limited extent are:
>
> - User runs some of our software, which uses our (old) C++ ABI
> - In that process, our old libstdc++ now comes higher in priority than the
> system one
> - later, some system library goes looking in libstdc++ (ours) and barfs,
> taking down the whole process.
>
> This is really a runtime concern, unfortunately, not a build-time linking
> problem.  I'm less concerned about the problem of telling people how to
> compile things correctly - package builders are smart people.  I just don't
> like the thought of accidental crashes when people have no idea what an ABI
> is.

Oh, I see, I didn't realize you were shipping libstdc++. Right,
shadowing the system libstdc++ with an old version is probably a bad
idea :-).

If you're shipping it anyway, then it seems like the solution to this
particular problem is "just" to ship a newer version of libstdc++ that
provides both ABIs? (I believe Julia uses a similar solution.)
Actually building this libstdc++ may be tricky, but once you've done
that then the runtime issue is solved, right?

(At least with respect to this ABI break. In the longer run, this
particular problem with shipping libstdc++ seems extra nasty, because
there are a whole class of changes that the libstdc++ developers would
*not* consider to be ABI breaks, but that will still break in your
case. E.g. if they change the internal representation of some opaque
type, and add new methods / new versions of methods that access this
internal representation -- which they do, from time to time -- then
everything is fine so long as you only have a single libstdc++ in
process, but as soon as you have two libstdc++'s in the same ELF
namespace with one partially shadowing the other, you are likely to
have a bad time.)

> This is a distro/package management problem, to be sure, but I think it's
> relevant for this group (and certainly for Continuum) to think about, since
> we (manylinux-builders) are the packagers, and consumers of wheels that use
> c++ may run into this.  I think the docker image PR I posted handles this in
> a reasonable way (providing two similar GCC's, each with different default
> C++ ABI settings) - and then we have to track which libstdc++ we send to
> people accordingly.  This is sort of your second proposal, I think.  We're
> counting on some modification to Conda in order to help obviate the user's
> need to know what an ABI is, or which one they have.

If you're shipping libstdc++ yourself, then why do you need to track
the distro packages and provide multiple GCCs, etc.? Surely you just
tell everyone to use the (new, backwards compatible) libstdc++ that
you ship?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org