[Wheel-builders] C++ ABI v5

[Michael Sarahan]

Indeed about shadowing. That is not the default. If people install libgcc,
they currently get 4.8.

I will look into creating a libstdc++ that has both abi's. I didn't realize
that was a possibility. Thanks!

Best,
Michael

On Wed, Mar 9, 2016, 18:58 Nathaniel Smith <njs at pobox.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/wheel-builders/attachments/20160310/08849b93/attachment.html>