multiple ports with stdlibc++ mismatches (all on 10.13)...

[Ryan Schmidt]

On May 31, 2018, at 10:44, Dr M J Carter wrote:

> On Thu, May 31, 2018 at 07:49:23AM -0700, Ken Cunningham wrote:
>> 
>> On 2018-05-30, at 11:04 PM, Joshua Root wrote:
>> 
>>> On 2018-5-31 15:39 , Ken Cunningham wrote:
>>>> gcc5 is using libstdc++ (this installation is configured to use libc++)
>>>> gcc6 is using libstdc++ (this installation is configured to use libc++)
>>>> gcc7 is using libstdc++ (this installation is configured to use libc++)
>>> 
>>> Did cxx_stdlib_overridden.tcl not set these up right for you?
>> 
>> It appears it should have...
>> 
>> I may have some inconsistency in my local MacPorts' database.
> 
> If so, that may not be the primary cause.  Our build system recreates
> MacPorts from scratch from the tarball; as of 2.5.0, openmpi-gcc6
> builds, 3+ times over, for everything which depends on it, then gets
> rejected each time due to the libstdc++/libc++ conflict.

That is expected: Josh was specifically asking about the gcc5, gcc6, gcc7 ports, because they clear configure.cxx_stdlib. The cxx_stdlib_overridden.tcl script contains a list of ports that were known to modify configure.cxx_stdlib at the time that MacPorts 2.5.0 was released, which includes gcc5, gcc6, gcc7.

openmpi-gcc6 is not such a port. It does not override the default value of configure.cxx_stdlib, yet because it builds with MacPorts FSF GCC, it does not use the standard C++ lib. It would be nice if MacPorts base knew that using MacPorts FSF GCC implied that configure.cxx_stdlib would change, but in 2.5.0, it doesn't know that, so any port building with MacPorts FSF GCC must specify configure.cxx_stdlib.