gcc7/libgcc7 problems

[Ken Cunningham]

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.webuse at 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.webuse at 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 <egall at gwmail.gwu.edu> wrote:
>> On 12/11/19, Ken Cunningham <ken.cunningham.webuse at 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...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191215/cc60cc4d/attachment.html>