Opened 6 years ago

Closed 5 years ago

#56616 closed defect (fixed)

flac: stdlibc++ mismatch

Reported by: iefdev (Eric F) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.5.2
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mojca (Mojca Miklavec)
Port: flac

Description

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

Attachments (2)

flac_main.log (296.1 KB) - added by iEFdev 6 years ago.
flac_CC_PRINT_OPTIONS (213.3 KB) - added by iEFdev 6 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 6 years ago by jmroot (Joshua Root)

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

comment:2 Changed 6 years ago by 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

Last edited 6 years ago by iEFdev (previous) (diff)

Changed 6 years ago by iEFdev

Attachment: flac_main.log added

Changed 6 years ago by iEFdev

Attachment: flac_CC_PRINT_OPTIONS added

comment:3 Changed 6 years ago by 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)

comment:4 in reply to:  3 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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
Last edited 6 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by 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

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:8 Changed 6 years ago by 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.

comment:9 in reply to:  6 Changed 6 years ago by 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).

comment:10 Changed 6 years ago by 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
Last edited 6 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:11 in reply to:  10 Changed 6 years ago by 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.

Last edited 6 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:12 Changed 6 years ago by 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.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:13 Changed 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:14 Changed 6 years ago by jmroot (Joshua Root)

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

comment:15 Changed 6 years ago by mf2k (Frank Schima)

Keywords: cxx_stdlib removed

comment:16 Changed 6 years ago by mojca (Mojca Miklavec)

Cc: mojca added

comment:17 Changed 5 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.