<p dir="ltr">Indeed about shadowing. That is not the default. If people install libgcc, they currently get 4.8.</p>
<p dir="ltr">I will look into creating a libstdc++ that has both abi's. I didn't realize that was a possibility. Thanks!</p>
<p dir="ltr">Best,<br>
Michael</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 9, 2016, 18:58 Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michael,<br>
<br>
On Wed, Mar 9, 2016 at 4:33 PM, Michael Sarahan <<a href="mailto:msarahan@gmail.com" target="_blank">msarahan@gmail.com</a>> wrote:<br>
> Hi Nathaniel,<br>
><br>
> Thanks for your feedback.  It sounds like you think this won't be much of an<br>
> issue, and I really hope you're right!  This feels something like the y2k<br>
> bug to me: apocalyptic predictions, but perhaps ultimately little impact.<br>
><br>
> The issues we have seen to a limited extent are:<br>
><br>
> - User runs some of our software, which uses our (old) C++ ABI<br>
> - In that process, our old libstdc++ now comes higher in priority than the<br>
> system one<br>
> - later, some system library goes looking in libstdc++ (ours) and barfs,<br>
> taking down the whole process.<br>
><br>
> This is really a runtime concern, unfortunately, not a build-time linking<br>
> problem.  I'm less concerned about the problem of telling people how to<br>
> compile things correctly - package builders are smart people.  I just don't<br>
> like the thought of accidental crashes when people have no idea what an ABI<br>
> is.<br>
<br>
Oh, I see, I didn't realize you were shipping libstdc++. Right,<br>
shadowing the system libstdc++ with an old version is probably a bad<br>
idea :-).<br>
<br>
If you're shipping it anyway, then it seems like the solution to this<br>
particular problem is "just" to ship a newer version of libstdc++ that<br>
provides both ABIs? (I believe Julia uses a similar solution.)<br>
Actually building this libstdc++ may be tricky, but once you've done<br>
that then the runtime issue is solved, right?<br>
<br>
(At least with respect to this ABI break. In the longer run, this<br>
particular problem with shipping libstdc++ seems extra nasty, because<br>
there are a whole class of changes that the libstdc++ developers would<br>
*not* consider to be ABI breaks, but that will still break in your<br>
case. E.g. if they change the internal representation of some opaque<br>
type, and add new methods / new versions of methods that access this<br>
internal representation -- which they do, from time to time -- then<br>
everything is fine so long as you only have a single libstdc++ in<br>
process, but as soon as you have two libstdc++'s in the same ELF<br>
namespace with one partially shadowing the other, you are likely to<br>
have a bad time.)<br>
<br>
> This is a distro/package management problem, to be sure, but I think it's<br>
> relevant for this group (and certainly for Continuum) to think about, since<br>
> we (manylinux-builders) are the packagers, and consumers of wheels that use<br>
> c++ may run into this.  I think the docker image PR I posted handles this in<br>
> a reasonable way (providing two similar GCC's, each with different default<br>
> C++ ABI settings) - and then we have to track which libstdc++ we send to<br>
> people accordingly.  This is sort of your second proposal, I think.  We're<br>
> counting on some modification to Conda in order to help obviate the user's<br>
> need to know what an ABI is, or which one they have.<br>
<br>
If you're shipping libstdc++ yourself, then why do you need to track<br>
the distro packages and provide multiple GCCs, etc.? Surely you just<br>
tell everyone to use the (new, backwards compatible) libstdc++ that<br>
you ship?<br>
<br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</blockquote></div>