It's hard to even debug, but as I understand it, some objects are created by system frameworks linked to /usr/lib/libstdc++.dylib.
The ones we create can have any linking we want them to have, but for c++11 support, we need to link them against /opt/local/lib/libgcc/libstdc++.dylib. So patching all the system frameworks to look at /opt/local/lib/libgcc/libstdc++.dylib woulc be similar to just replacing /usr/lib/libstdc++.dylib with a new version in severity. I suppose getting libc++ working on PowerPC and using that by default is probably the best option, if we can do that. Good thing we already have done that on 10.6 and up! Sooner or later this would have happened there too... K On 2019-12-15, at 12:13 PM, Ruben Di Battista wrote: > Isn't something similar to what patchelf does possible on macOs? Editing the > RPATH? > > On Sun, 15 Dec 2019, 19:06 Ken Cunningham, <ken.cunningham.web...@gmail.com> > wrote: > This issue is a classic c++ standard lib mixup, exactly what we have always > feared and tried our best to avoid on MacPorts. > > Objects are being created using /usr/lib/libstdc++.dylib and then (in this > case) attempt to be deleted by /opt/local/lib/libstdc++.dylib and they are > not matching up, so errors are happening. > > We've discussed this exact situation for years, but until now, it has not > happened. > > Solutions are tricky. Upstream is trying to see if they can tweak libgcc7 > 7.5.0 to not error out, like libgcc7 7.4.x did not error out. Maybe that > might work. Dunno. > > We can set the DYLD_LIBRARY_PATH to point to /opt/local/lib/libgcc/ and so > software will look there first. That works. Getting it to always apply to all > software is a bit tricky... > > You can set up a chroot environment, and run your software there -- good luck > -- if you know how to do that, you're probably not trying to run libgcc7 on a > 15 year old PowerMac. > > Or -- get ready for it -- we can update the libgcc in /usr/lib to a current > one, like the one from libgcc7 with some kind of installer that we supply > (and maintain, and and and). I can hear the groans now. > > We could, perhaps, get libc++ working on PowerMac, and use that -- it would, > naturally, have no such interaction with /usr/lib/libstdc++.dylib and > therefore problem solved. > > So -- working on it. For now, libgcc7 7.4.x is magically immune, it appears, > at least so far as we know, for now. > > K > > > On Dec 11, 2019, at 12:58, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > >> Iain has asked for a minimal reproducer and a bisected commit that generated >> the error. Then it's worth opening the bug report. >> >> I tried a few different iostream with locale test files, but so far couldn't >> repro the error. >> >> Best, >> >> Ken >> >> On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager <eg...@gwmail.gwu.edu> wrote: >> On 12/11/19, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: >> > We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386 >> > (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in >> > memory handling, possibly related to locale support, maybe some other thing >> > TBA). >> > >> > We may have to bump epoch and roll back to last 7.4.x unless we can get >> > this sorted out soon, as tickets are starting up... >> > >> > Ken >> > >> >> Is there an upstream bug filed in the GCC Bugzilla about this? I >> realize the branch for 7 is closed now, but it could be due to a >> change backported from a different branch where it's also relevant...
