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

[iEFdev]

Sorry for the late reply. I showed up in an upgrade this morning and biult fine 
now.

I'll add tickets for the others. Thanks...

· Eric


On 6/1/18 5:24 , Ryan Schmidt wrote:
> On May 31, 2018, at 12:21, iEFdev wrote:
>
>> I have some 5-6 ports that show this (gptfdisk, flac, etc.).
> gptfdisk: https://github.com/macports/macports-ports/pull/1910
>
> flac: I do not see anything wrong with the port. Every invocation of the 
> clang++ already specifies the -stdlib flag. If that's not happening for you, 
> please file a ticket with a main.log file attached.
>
> etc.: File tickets or PRs.
>
>

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

[Joshua Root]

On 2018-6-2 07:26 , Andrew Moore wrote:
> On May 31, 2018, at 11:44 AM, 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.
>>
>> 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.
> 
> Just to clarify (someone please correct me if I’m wrong), a conflict is 
> reported
> for openmpi-gcc (and other ports) that link against against 
> ${prefix}/lib/libstdc++.x.dylib
> (provided by libgcc), but openmpi-gcc is okay.
> 
> Until the issue is resolved in MacPorts, you can:
> 
> 1) Ignore the reported conflict,
> 
> 2) If  CXX linkage isn’t needed in openmpi-gcc, remove it from openmpi 
> Portfile
> (i.e., remove from `configure.args’ `—enable-mpi-cxx’, which is disabled by 
> default),
> 
> 3) Update cxx_stdlib_overridden.tcl to include openmpi-gcc.  This is a hack, 
> and
> could damage your registry.  Caveat emptor.

The correct fix is not really any harder: set configure.cxx_stdlib to
macports-libstdc++ in the Portfile.

- Josh

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

[Joshua Root]

On 2018-6-2 06:09 , Rainer Müller wrote:
> On 2018-05-31 17:39, Rainer Müller wrote:
>> On 2018-05-31 16:49, 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.
>>
>> Were you running master at some point on this installation? This might
>> be what I described in the following ticket, but was subsequently fixed
>> on master. However, any installation that was converted with master
>> before the fix will be left in this state.
>>
>> https://trac.macports.org/ticket/56326
> 
> Hm, have the gcc* ports been rev-bumped after the release of 2.5.0?
> 
> The problem could be that the archives do not contain any cxx_stdlib.
> The cxx_stdlib_overridden.tcl script helps upgrading users, but those
> that install the port from the archive will experience the same problem
> I reported in that ticket.

Ah, that's true. That was an unfortunate oversight, as
cxx_stdlib_overridden can be derived from the Portfile when installing.



- Josh

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

[Andrew Moore]

On May 31, 2018, at 11:44 AM, 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.
> 
> 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.

Just to clarify (someone please correct me if I’m wrong), a conflict is reported
for openmpi-gcc (and other ports) that link against against 
${prefix}/lib/libstdc++.x.dylib
(provided by libgcc), but openmpi-gcc is okay.

Until the issue is resolved in MacPorts, you can:

1) Ignore the reported conflict,

2) If  CXX linkage isn’t needed in openmpi-gcc, remove it from openmpi Portfile
(i.e., remove from `configure.args’ `—enable-mpi-cxx’, which is disabled by 
default),

3) Update cxx_stdlib_overridden.tcl to include openmpi-gcc.  This is a hack, and
could damage your registry.  Caveat emptor.
-AM

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

[Rainer Müller]

On 2018-05-31 17:39, Rainer Müller wrote:
> On 2018-05-31 16:49, 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.
> 
> Were you running master at some point on this installation? This might
> be what I described in the following ticket, but was subsequently fixed
> on master. However, any installation that was converted with master
> before the fix will be left in this state.
> 
> https://trac.macports.org/ticket/56326

Hm, have the gcc* ports been rev-bumped after the release of 2.5.0?

The problem could be that the archives do not contain any cxx_stdlib.
The cxx_stdlib_overridden.tcl script helps upgrading users, but those
that install the port from the archive will experience the same problem
I reported in that ticket.

Rainer

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

[Ryan Schmidt]

On May 31, 2018, at 00:39, Ken Cunningham wrote:

> pbzip2 is using libstdc++ (this installation is configured to use libc++)

I can't see why this would be. The build only invokes the C++ compiler once, 
and does pass the -stdlib flag when doing so. Please file a ticket with a 
main.log and any other information you can think of.


> dylibbundler is using libstdc++ (this installation is configured to use 
> libc++)

https://github.com/macports/macports-ports/pull/1912


> lzma is using libstdc++ (this installation is configured to use libc++)

https://github.com/macports/macports-ports/commit/536ead384df3ad8539bde8d02082a0aa5edf55be


> SuiteSparse is using libstdc++ (this installation is configured to use libc++)

https://github.com/macports/macports-ports/pull/1913


> starfighter is using libstdc++ (this installation is configured to use libc++)

https://github.com/macports/macports-ports/commit/72df4a91fd7c53634579ddd3d263aed6291d7458


> darwinbuild is using libstdc++ (this installation is configured to use libc++)

I can't see a problem with this port; file a ticket with more info.


> pdftk is using libstdc++ (this installation is configured to use libc++)

Due to the use of FSF GCC. https://trac.macports.org/ticket/56554

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

[Ryan Schmidt]

On May 31, 2018, at 12:21, iEFdev wrote:

> I have some 5-6 ports that show this (gptfdisk, flac, etc.).

gptfdisk: https://github.com/macports/macports-ports/pull/1910

flac: I do not see anything wrong with the port. Every invocation of the 
clang++ already specifies the -stdlib flag. If that's not happening for you, 
please file a ticket with a main.log file attached.

etc.: File tickets or PRs.

Re: 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.

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

[Ken Cunningham]

On 2018-05-31, at 5:53 PM, Joshua Root wrote:

> Those that do provide or use C++ libraries need to be fixed to use the
> C++ stdlib that they are being told to use.

And indeed, that is the exact point of having this test and check ... to find 
and fix these broken ports.

Ken

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

[Joshua Root]

On 2018-6-1 09:49 , iEFdev wrote:
> 
> Aah, ok… So, for flac it need its own.
> 
> I made a test using: “configure.cxx_stdlib libFLAC++” instead, and that
> was working as well.

Sorry if I wasn't clear: libFLAC++ is a library provided by the flac
port. It is linked to the C++ stdlib. Programs that use libFLAC++ need
to use the same stdlib that libFLAC++ does. The way to ensure that is to
make sure libFLAC++ is built against the stdlib that has been selected
for the MacPorts installation as a whole (whether that's libstdc++ or
libc++).

The bottom line is that changing configure.cxx_stdlib in the flac port
is not a solution. It needs to be fixed to build against the cxx_stdlib
that is selected.

> But, since you wrote:
>> These need to be fixed by either making them link with the selected stdlib 
>> (preferred), or changing configure.cxx_stdlib to match what they are 
>> actually using.
> And the debug said: “flac is using libstdc++ (this installation is
> configured to use libc++)” - I thought it suppose to be the first one.

Yes, flac was using libstdc++ even though it had been told to use
libc++. That needs to be fixed.

> When unistalling flac &/or doing a rev-upgrade, it says it'll breake:
> 
> --->  Unable to uninstall flac @1.3.2_0, the following ports depend on it:
> --->  libsndfile @1.0.28_0
> --->  sox @14.4.2_1
> 
> So, I guess that's 2 ones that is using it. rev-upgrade says there are
> no broken ports.

I don't know whether those ports are using libFLAC++ or just libFLAC.

> The ports: wxWidgets, pgAdmin3, gptfdisk, flac
> 
> Should I create some tickets? or PRs/patches adding
> “configure.cxx_stdlib libstdc++” (except flac) for those?
> // ...or should it be “configure.cxx_stdlib ${configure.cxx_stdlib}” to
> get what ever is set.

For ports that don't provide or use any C++ libraries, you can get away
with changing configure.cxx_stdlib to match what they're already doing.
Those that do provide or use C++ libraries need to be fixed to use the
C++ stdlib that they are being told to use.

- Josh

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

[iEFdev]

On 6/1/18 0:36 , Joshua Root wrote:
> On 2018-6-1 07:24 , iEFdev wrote:
>> I made a quick test on flac, adding:
>>
>> # flac is using libstdc++ (this installation is configured to use libc++)
>> configure.cxx_stdlib libstdc++
>>
>> …and the rev-upgrade let it pass.
>>
>>> Please open tickets or better yet PRs for affected ports.
>>>
>>> - Josh
>> Since I'm on an older system, with libcxx set in my config files -
>> wouldn't a ticket be a better option in case this is a no-error? Perhaps
>> it should be wrapped around a check for what macos version, etc?
>>
>> When searching I saw this one (non-related):
>> https://lists.macports.org/pipermail/macports-dev/2015-April/030230.html
>>
>> So perhaps something like:
>>
>> if {[string equal ${configure.cxx_stdlib} "libc++"]} {
>> configure.cxx_stdlib libstdc++
>> }
>>
>> Would that be a better approach?
> Unfortunately using a different stdlib than the system-wide choice is
> not an option for flac, as it provides libFLAC++ which is used by other
> things. All C++ programs need to be using the same stdlib as all the C++
> libraries they use, so effectively all C++ libraries have to use the
> system-wide stdlib (as set in macports.conf in your case, but it's
> equally true if the stdlib was auto-selected based on the platform).
>
> Programs that are written in C++ but don't use or export any C++
> libraries can get away with using a different stdlib.
>
> If you don't happen to have anything installed that uses libFLAC++, you
> of course won't see the problems resulting from a stdlib mismatch there.
>
> - Josh
>
Aah, ok… So, for flac it need its own.

I made a test using: “configure.cxx_stdlib libFLAC++” instead, and that was
working as well.

But, since you wrote:
> These need to be fixed by either making them link with the selected stdlib 
> (preferred), or changing configure.cxx_stdlib to match what they are actually 
> using.
And the debug said: “flac is using libstdc++ (this installation is configured to
use libc++)” - I thought it suppose to be the first one.

When unistalling flac &/or doing a rev-upgrade, it says it'll breake:

--->  Unable to uninstall flac @1.3.2_0, the following ports depend on it:
--->libsndfile @1.0.28_0
--->sox @14.4.2_1

So, I guess that's 2 ones that is using it. rev-upgrade says there are no broken
ports.

- - -

The ports: wxWidgets, pgAdmin3, gptfdisk, flac

Should I create some tickets? or PRs/patches adding “configure.cxx_stdlib
libstdc++” (except flac) for those?
// ...or should it be “configure.cxx_stdlib ${configure.cxx_stdlib}” to get what
ever is set.

· Eric

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

[Joshua Root]

On 2018-6-1 07:24 , iEFdev wrote:
> 
> I made a quick test on flac, adding:
> 
> # flac is using libstdc++ (this installation is configured to use libc++)
> configure.cxx_stdlib libstdc++
> 
> …and the rev-upgrade let it pass.
> 
>> Please open tickets or better yet PRs for affected ports.
>>
>> - Josh
> 
> Since I'm on an older system, with libcxx set in my config files -
> wouldn't a ticket be a better option in case this is a no-error? Perhaps
> it should be wrapped around a check for what macos version, etc?
> 
> When searching I saw this one (non-related):
> https://lists.macports.org/pipermail/macports-dev/2015-April/030230.html
> 
> So perhaps something like:
> 
> if {[string equal ${configure.cxx_stdlib} "libc++"]} {
> configure.cxx_stdlib libstdc++
> }
> 
> Would that be a better approach?

Unfortunately using a different stdlib than the system-wide choice is
not an option for flac, as it provides libFLAC++ which is used by other
things. All C++ programs need to be using the same stdlib as all the C++
libraries they use, so effectively all C++ libraries have to use the
system-wide stdlib (as set in macports.conf in your case, but it's
equally true if the stdlib was auto-selected based on the platform).

Programs that are written in C++ but don't use or export any C++
libraries can get away with using a different stdlib.

If you don't happen to have anything installed that uses libFLAC++, you
of course won't see the problems resulting from a stdlib mismatch there.

- Josh

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

[iEFdev]

On 5/31/18 21:24 , Joshua Root wrote:
> On 2018-6-1 03:21 , iEFdev wrote:
>> Hi,
>>
>> I have some 5-6 ports that show this (gptfdisk, flac, etc.). Do you have
>> an example how to use the cxx_stdlib_overridden.tcl, or are there any
>> documentation to read more how to use it. Sorry, if it's obvious, but I
>> couldn't find it.
>>
>> /// Since I'm using 10.7.5 with the CXX-fix
>> ,
>> I'm not really sure if it the port(s) or my setup that triggers it.//
> cxx_stdlib_overridden.tcl is a script that runs automatically when
> MacPorts base is installed. It sets up some metadata in the registry.
>
> The ports that rev-upgrade is newly finding to be broken are those that
> have configure.cxx_stdlib set to libc++ but in fact link with libstdc++,
> or vice versa. These need to be fixed by either making them link with
> the selected stdlib (preferred), or changing configure.cxx_stdlib to
> match what they are actually using.
Thanks Josh,

I made a quick test on flac, adding:

# flac is using libstdc++ (this installation is configured to use libc++)
configure.cxx_stdlib libstdc++

…and the rev-upgrade let it pass.

> Please open tickets or better yet PRs for affected ports.
>
> - Josh

Since I'm on an older system, with libcxx set in my config files - wouldn't a
ticket be a better option in case this is a no-error? Perhaps it should be
wrapped around a check for what macos version, etc?

When searching I saw this one (non-related):
https://lists.macports.org/pipermail/macports-dev/2015-April/030230.html

So perhaps something like:

if {[string equal ${configure.cxx_stdlib} "libc++"]} {
configure.cxx_stdlib libstdc++
}

Would that be a better approach?

· Eric

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

[Joshua Root]

On 2018-6-1 03:21 , iEFdev wrote:
> Hi,
> 
> I have some 5-6 ports that show this (gptfdisk, flac, etc.). Do you have
> an example how to use the cxx_stdlib_overridden.tcl, or are there any
> documentation to read more how to use it. Sorry, if it's obvious, but I
> couldn't find it.
> 
> /// Since I'm using 10.7.5 with the CXX-fix
> ,
> I'm not really sure if it the port(s) or my setup that triggers it.//

cxx_stdlib_overridden.tcl is a script that runs automatically when
MacPorts base is installed. It sets up some metadata in the registry.

The ports that rev-upgrade is newly finding to be broken are those that
have configure.cxx_stdlib set to libc++ but in fact link with libstdc++,
or vice versa. These need to be fixed by either making them link with
the selected stdlib (preferred), or changing configure.cxx_stdlib to
match what they are actually using.

Please open tickets or better yet PRs for affected ports.

- Josh

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

[iEFdev]

Hi,

I have some 5-6 ports that show this (gptfdisk, flac, etc.). Do you have an
example how to use the cxx_stdlib_overridden.tcl, or are there any documentation
to read more how to use it. Sorry, if it's obvious, but I couldn't find it.

/// Since I'm using 10.7.5 with the CXX-fix
, I'm
not really sure if it the port(s) or my setup that triggers it.//
/
· Eric


On 5/31/18 8:04 , 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?

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

[Dr M J Carter]

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.

Apologies if this comes across as abrupt  I've been banging my
head on this all day.  Suggestion: could the conflict message be made
to appear without the -v flag, please?

Hope this helps.  More details once a test build with only gcc7 and
openmpi-gcc7, both from source (there's hints that that might help),
has finished, but it's not looking good so far.

-- 
Dr Martin J Carter
Computer System Administrator
Astrophysics, University of Oxford

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

[Rainer Müller]

On 2018-05-31 16:49, 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.

Were you running master at some point on this installation? This might
be what I described in the following ticket, but was subsequently fixed
on master. However, any installation that was converted with master
before the fix will be left in this state.

https://trac.macports.org/ticket/56326

Rainer

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

[Ken Cunningham]

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.

I made the error one time of offloading some of my larger installed port 
tarballs onto a backup drive, and this turned out to cause troubles during 
MacPorts upgrades at times.

Up until now, it had not been a huge deal.

I will investigate.

Thanks,

Ken

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

[Ryan Schmidt]

On May 31, 2018, at 00:39, Ken Cunningham wrote:

> pbzip2 is using libstdc++ (this installation is configured to use libc++)
> dylibbundler is using libstdc++ (this installation is configured to use 
> libc++)
> lzma is using libstdc++ (this installation is configured to use libc++)
> SuiteSparse is using libstdc++ (this installation is configured to use libc++)
> starfighter is using libstdc++ (this installation is configured to use libc++)
> darwinbuild is using libstdc++ (this installation is configured to use libc++)
> pdftk is using libstdc++ (this installation is configured to use libc++)
> 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++)


Each port is going to need to be investigated and fixed in its own unique way, 
so an individual ticket should be filed for each port (or each group of ports). 
It may be quicker just to try to fix them and commit them without tickets. 
pdftk already has a ticket.

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

[Joshua Root]

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?