<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><p><span style="background-color: rgba(255, 255, 255, 0);">This issue is a classic c++ standard lib mixup, exactly what we have always feared and tried our best to avoid on MacPorts.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">Objects are being created using <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">/usr/lib/libstdc++.dylib</code> and then (in this case) attempt to be deleted by <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">/opt/local/lib/libstdc++.dylib</code> and they are not matching up, so errors are happening. </span></p><p><span style="background-color: rgba(255, 255, 255, 0);">We've discussed this exact situation for years, but until now, it has not happened.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">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.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">We can set the DYLD_LIBRARY_PATH to point to <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">/opt/local/lib/libgcc/</code> and so software will look there first. That works. Getting it to always apply to all software is a bit tricky...</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">You can set up a <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">chroot</code> 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.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">Or -- get ready for it -- we can update the libgcc in <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">/usr/lib</code> to a current one, like the one from <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">libgcc7</code> with some kind of installer that we supply (and maintain, and and and). I can hear the groans now.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">We could, perhaps, get libc++ working on PowerMac, and use that -- it would, naturally, have no such interaction with <code style="border: 1px solid rgb(238, 221, 204); border-top-left-radius: 0.25em; border-top-right-radius: 0.25em; border-bottom-right-radius: 0.25em; border-bottom-left-radius: 0.25em; padding: 0px 0.3em;">/usr/lib/libstdc++.dylib</code> and therefore problem solved.</span></p><p><span style="background-color: rgba(255, 255, 255, 0);">So -- working on it. For now, libgcc7 7.4.x is magically immune, it appears, at least so far as we know, for now.</span></p></div><div>K</div><div><br></div><div><br>On Dec 11, 2019, at 12:58, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div>Iain has asked for a minimal reproducer and a bisected commit that generated the error. Then it's worth opening the bug report.<br><br></div><div>I tried a few different iostream with locale test files, but so far couldn't repro the error.<br></div><div><br></div>Best,<br><br></div>Ken<br></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Wed, Dec 11, 2019 at 12:11 PM Eric Gallager <<a href="mailto:egall@gwmail.gwu.edu">egall@gwmail.gwu.edu</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">On 12/11/19, Ken Cunningham <<a target="_blank" href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br>
> We're having troubles with the recent gcc7 upgrade to 7.5.0 on i386<br>
> (bootstrapping with non-system assembler) and on 10.5 PPC (bus errors in<br>
> memory handling, possibly related to locale support, maybe some other thing<br>
> TBA).<br>
><br>
> We may have to bump epoch and roll back to last 7.4.x unless we can get<br>
> this sorted out soon, as tickets are starting up...<br>
><br>
> Ken<br>
><br>
<br>
Is there an upstream bug filed in the GCC Bugzilla about this? I<br>
realize the branch for 7 is closed now, but it could be due to a<br>
change backported from a different branch where it's also relevant...<br>
</blockquote></div>
</div></blockquote></body></html>