> On Sep 11, 2018, at 11:09 AM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: > > > On 2018-09-11, at 5:13 AM, David wrote: > >> >>> On Sep 11, 2018, at 5:00 AM, macports-users-requ...@lists.macports.org >>> wrote: >>> >>> Date: Mon, 10 Sep 2018 22:49:05 -0700 >>> From: Ken Cunningham <ken.cunningham.web...@gmail.com> >>> To: MacPorts Users <macports-us...@lists.macosforge.org> >>> Subject: Re: Help diagnosing gcc7 on MacOS 10.13 and SIGABRT >>> Message-ID: <7748ed5d-5352-4d32-993c-b9d1dba54...@gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>>> run() is in generated code that we compile and link to the system as a >>>> shared library. >>> >>> >>> Is the generated code in the shared library compiled and linked to the >>> system and against libc++ by any chance? >>> >>> >>> If it is, then your gcc7 code is not linked against libc++, but against >>> /opt/local/bin/libstdc++ >>> >>> and your c++ standard libs and c++ abis would be different. >>> >>> Would be surprising if it worked at all, I would think. >>> >>> If I'm following your issue correctly. >>> >>> K >> >> All compiled using the same libraries. The throw logic comes from >> libgcc_s.1.dylib and that appears to be the same between the two machines. >> >> Working Version (10.10.5) >> .binaries/sbx_go: >> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current >> version 1.2.11) >> /opt/local/lib/libidn2.0.dylib (compatibility version 4.0.0, current >> version 4.4.0) >> /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current >> version 10.5.0) >> /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current >> version 8.7.0) << Changes >> /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current >> version 1.0.0) >> /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> /opt/local/lib/libpsl.5.dylib (compatibility version 9.0.0, current >> version 9.1.0) >> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, >> current version 7.24.0) << Changes >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 1213.0.0) << Changes >> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> >> internal.0/code/1/0.dylib: >> code/1/0.dylib (compatibility version 0.0.0, current version 0.0.0) >> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, >> current version 7.24.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 1213.0.0) >> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> >> Failing Version: (10.13.6) >> 659_ otool -L .binaries/sbx_go >> .binaries/sbx_go: >> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current >> version 1.2.11) >> /opt/local/lib/libidn2.0.dylib (compatibility version 4.0.0, current >> version 4.4.0) >> /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current >> version 10.5.0) >> /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current >> version 8.8.0) << Changes >> /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current >> version 1.0.0) >> /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> /opt/local/lib/libpsl.5.dylib (compatibility version 9.0.0, current >> version 9.1.0) >> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, >> current version 7.25.0) << Changes >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 1252.50.4) << Changes >> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> >> failing shared library >> internal.0/code/1/0.dylib: >> code/1/0.dylib (compatibility version 0.0.0, current version 0.0.0) >> /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, >> current version 7.25.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 1252.50.4) >> /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, >> current version 1.0.0) >> > > We'll still no explanation, but -- if any of those linked in librarires -- or > any of the recursively linked in libraries from those libraries (etc etc) -- > are linked against libc++ instead of libstdc++, it could cause a failure. > > This is why using gcc and c++ on macOS can be very tricky. > > Are you sure you can't build your software with clang and link it against > libc++? > > K
Interesting you should mention Clang. I’ve been building with clang for some time and though to try that only yesterday as a ‘try this, what can it hurt’ thought. And Lo - the failure stopped. Throwing with Clang works as expected. So I guess I’ll have to go with your thought that using GCC on 10.13 is just a bad idea. David