Isn't something similar to what patchelf does possible on macOs? Editing the RPATH?
On Sun, 15 Dec 2019, 19:06 Ken Cunningham, <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >> On 12/11/19, Ken Cunningham <[email protected]> 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... >> >
