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...
