On 2018-09-11, at 5:13 AM, David wrote:
> >> On Sep 11, 2018, at 5:00 AM, [email protected] wrote: >> >> Date: Mon, 10 Sep 2018 22:49:05 -0700 >> From: Ken Cunningham <[email protected]> >> To: MacPorts Users <[email protected]> >> Subject: Re: Help diagnosing gcc7 on MacOS 10.13 and SIGABRT >> Message-ID: <[email protected]> >> 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
