macports-users Digest, Vol 145, Issue 10

Ken Cunningham ken.cunningham.webuse at gmail.com
Tue Sep 11 18:09:32 UTC 2018


On 2018-09-11, at 5:13 AM, David wrote:

> 
>> On Sep 11, 2018, at 5:00 AM, macports-users-request at lists.macports.org wrote:
>> 
>> Date: Mon, 10 Sep 2018 22:49:05 -0700
>> From: Ken Cunningham <ken.cunningham.webuse at gmail.com>
>> To: MacPorts Users <macports-users at lists.macosforge.org>
>> Subject: Re: Help diagnosing gcc7 on MacOS 10.13 and SIGABRT
>> Message-ID: <7748ED5D-5352-4D32-993C-B9D1DBA54371 at 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


More information about the macports-users mailing list