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 <[email protected]> wrote: > Hi Michael, > > On Wed, Mar 9, 2016 at 4:33 PM, Michael Sarahan <[email protected]> > 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 >
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
