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

[angelog0 (Angelo Graziosi)]

After there was the upgrade to 2.5.0

sudo port selfupdate

it found pdftk port broken

--->  Scanning binaries for linking errors
--->  No broken files found.
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: pdftk @2.02+gcc5
Continue? [Y/n]:
[...]

but then after 3 builds it still failed

Error: Port pdftk is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port pdftk still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

So

sudo port -d -y rev-upgrade

The output is attached.

[ryandesign (Ryan Carsten Schmidt)]

The log says:

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

This is intentional, to the extent that pdftk intentionally builds using MacPorts gcc, which uses libstdc++. I don't know what I'm supposed to change in this port to make the error go away.

[kencu (Ken)]

Putting this in the Portfile should do it:

configure.cxx_stdlib libstdc++

at least that is what you told me.

[ryandesign (Ryan Carsten Schmidt)]

configure.cxx_stdlib libstdc++ means the port uses /usr/lib/libstdc++.6.dylib, which is not the case here. configure.cxx_stdlib macports-libstdc++ means the port uses /opt/local/lib/libgcc/libstdc++.6.dylib, which is the case here, but I was not expecting each port that compiles with MacPorts g++ to have to do that individually. Why should that be necessary? Why can't MacPorts base do it automatically when a port is using MacPorts g++?

[kencu (Ken)]

I certainly hope that we haven't differentiate between libstdc++ and macports-libstdc++ in this logic. We have gone to great pains to make them compatible with each other, and differentiating between them would generate a horrid mess.

The error states pdftk is using libstdc++ so I believe that is what it wants to see.

A 10 second test should answer the question quite readily for the OP.

This is but the first of many such tickets I suspect, and as you pointed out, "We'll have to fix them all".

[raimue (Rainer Müller)]

Replying to kencu:

I certainly hope that we haven't to differentiate between libstdc++ and macports-libstdc++ in this logic. We have gone to great pains to make them compatible with each other at least on systems where it occurs commonly (cxx11 PG), and differentiating between them would generate a horrid mess.

The point of enforcing configure.cxx_stdlib was to make linkage consistent and to allow selection of a matching precompiled archive. Using either libstdc++ or macports-libstdc++ will change the result on disk and is therefore considered to be different.

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue:

Replying to kencu:

I certainly hope that we haven't to differentiate between libstdc++ and macports-libstdc++ in this logic. We have gone to great pains to make them compatible with each other at least on systems where it occurs commonly (cxx11 PG), and differentiating between them would generate a horrid mess.

The point of enforcing configure.cxx_stdlib was to make linkage consistent and to allow selection of a matching precompiled archive. Using either libstdc++ or macports-libstdc++ will change the result on disk and is therefore considered to be different.

The result on disk for pdftk, right now, is that it links with /opt/local/lib/libgcc/libstdc++.6.dylib, which is what configure.cxx_stdlib macports-libstdc++ means.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

This is but the first of many such tickets I suspect, and as you pointed out, "We'll have to fix them all".

Yes, I did say that somewhere, but I was never referring to ports that specifically request to use MacPorts FSF g++. Granted there should be very few of those these days, but I had expected that MacPorts base would be able to understand that all ports that use MacPorts FSF g++ will obviously link with /opt/local/lib/libgcc/libstdc++.6.dylib, and that therefore they would assume configure.cxx_stdlib is macports-libstdc++.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #56590.

This bug in MacPorts 2.5.0 has been fixed and will be released soon in MacPorts 2.5.1.

[jmgoicolea (Jose Goicolea)]

Solved for me with 2.5.1, thanks!