flac: stdlibc++ mismatch

[iefdev (Eric F)]

There's a mismatch between the libraries.

$ sudo port -d -y rev-upgrade
#snip
flac is using libstdc++ (this installation is configured to use libc++)

ref. from the ​mailing list

[jmroot (Joshua Root)]

Please attach the build log. Can you also find out which files are linked with libstdc++ with otool -L?

[iEFdev]

$ otool -L /opt/local/lib/libgcc/libstdc++.6.dylib
/opt/local/lib/libgcc/libstdc++.6.dylib:
        /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 159.1.0)
        /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

---

Build log? Is it the main.log - after an install? Or the .CC_PRINT_OPTIONS int the build->work folder?

# adding both

[kencu (Ken)]

Try rebuilding it once. Maybe you built it during the brief 2.5.1 era. I have 10.6.8 / libc++ and it seems to be fine:

$ otool -L /opt/local/lib/libFLAC++.dylib
/opt/local/lib/libFLAC++.dylib:
	/opt/local/lib/libFLAC++.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libFLAC.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)

[iEFdev]

Replying to kencu:

Try rebuilding it once. Maybe you built it during the brief 2.5.1 era. I have 10.6.8 / libc++ and it seems to be fine:

To get the log above, I uninstalled it, to install it again (always from source-builds).

No it's been like this since all these errors started (see mailing list).

$ otool -L /opt/local/lib/libFLAC++.dylib
/opt/local/lib/libFLAC++.dylib:
	/opt/local/lib/libFLAC++.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libFLAC.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)

If I check against the libFLAC++ I get a different output than you.

$ otool -L /opt/local/lib/libFLAC++.dylib
/opt/local/lib/libFLAC++.dylib:
        /opt/local/lib/libFLAC++.6.dylib (compatibility version 10.0.0, current version 10.0.0)
        /opt/local/lib/libFLAC.8.dylib (compatibility version 12.0.0, current version 12.0.0)
        /opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.3.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

Perhaps I've missed something when I applied the LibcxxOnOlderSystems-fix? I followed the Lion/ML section.

[kencu (Ken)]

Ah, I think the compiler blacklisting is pushing you back to an old gcc compiler...ergo the breakage.

I believe those instructions might best now include setting a default compiler in macports.conf (point 11) on Lion / ML as well.

something like this in macports.conf should do it:

default_compilers macports-clang-5.0

[ryandesign (Ryan Carsten Schmidt)]

Ken replied while I was writing this reply, but here it is:

Aha—the log shows it's using llvm-gcc-4.2 (or rather llvm-g++-4.2) which does not support libc++. Only clang supports libc++. gcc-4.0, gcc-4.2, apple-gcc-4.2, and all the FSF GCC versions don't support libc++ either.

I'm not sure what the correct fix is.

We could modify this port and all other ports that use C++ to blacklist non-clang compilers. Identifying those ports is a bit of work, and it would unnecessarily exclude those compilers on systems that use libstdc++, where non-clang compilers would work fine.

Or we could modify base to remove non-clang compilers from the list of possible compilers when configure.cxx_stdlib is libc++. But that would unnecessarily exclude those compilers from ports that don't use C++, where those compilers would work fine.

The problem is that the default list of compilers and the blacklist that ports can apply to it has to do with a compiler collection, which usually includes a C compiler, a C++, compiler, an Objective-C compiler, an Objective-C++ compiler, and a C preprocessor, and sometimes other compilers like Java or Fortran compilers. And now what we want to do is impose additional restrictions only on the C++ compiler (and Objective-C++ compiler) parts of that collection. The code in portconfigure.tcl that builds up the default list of compilers is probably the place where these changes would have to happen.

[kencu (Ken)]

Right.

FYI I set my default compiler in macports.conf to clang 3.9 about a year ago on SL, and have almost never had a problem since. That might indeed be the best/easiest solution for these systems, although I'd go with clang 5.0 now

[ryandesign (Ryan Carsten Schmidt)]

Ken, we need a solution that does not involve users manually changing settings. In a near-future version of MacPorts, we want to migrate all users of 10.6-10.8 to libc++ by default, so we need base and portfiles to choose suitable compilers on their own.

[iEFdev]

Replying to ryandesign:

Ken replied while I was writing this reply, but here it is:

Aha—the log shows it's using llvm-gcc-4.2 (or rather llvm-g++-4.2) which does not support libc++. Only clang supports libc++. gcc-4.0, gcc-4.2, apple-gcc-4.2, and all the FSF GCC versions don't support libc++ either.

I'm not sure what the correct fix is.

# snip

The code in portconfigure.tcl that builds up the default list of compilers is probably the place where these changes would have to happen.

And meanwhile… what would make a good (temp fix), for now? Make it a local port, specifying a suitable compiler in it? and then rebuild it again when these changes are made (ie portconfigure.tcl).

[kencu (Ken)]

You could just do what I suggested for now, and revert it someday when macports defaults to libc++ and all the kinks have been worked out in portconfigure.tcl

or build this one as a one-off, and hope there aren't many more like this

sudo port -v install flac configure.compiler=macports-clang-5.0

[iEFdev]

Replying to kencu:

You could just do what I suggested for now, and revert it someday when macports defaults to libc++ and all the kinks have been worked out in portconfigure.tcl

or build this one as a one-off, and hope there aren't many more like this

sudo port -v install flac configure.compiler=macports-clang-5.0

Thanks… I'll do both. :)

I made a one-off now (flac), and I can add it to macport.conf later when the tickets I have are closed.

[kencu (Ken)]

@Ryan -- I guess we should either add the recommendation to add a new set of default_compilers manually in macports.conf for 10.7 and 10.8 as currently recommended in LibcxxOnOlderSystems for SnowLeopard and Leopard, or alternatively come up with some way of setting them appropriately in portconfigure.tcl branching on whether the cxx_stdlib is libc++ or libstdc++.

That latter idea doesn't sound overly hard, and we just need to ponder through the possible issues with bootstrapping to a system that has macports-clang-5.0 installed to make sure we don't mess that up.

[jmroot (Joshua Root)]

Yes, LibcxxOnOlderSystems should say to specify default_compilers everywhere. Getting base ready for the changeover is #56041.