<div dir="auto">Isn't something similar to what patchelf does possible on macOs? Editing the RPATH? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 15 Dec 2019, 19:06 Ken Cunningham, <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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 href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" rel="noreferrer">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></div></blockquote></div>