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
