Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#50249 closed defect (fixed)

qt5-qtbase uses libstdc++ if C++11 support was not explicitly requested

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.3.99
Keywords: Cc:
Port: qt5-qtbase

Description

qt5-qtbase is programmed to build software using libstdc++ if C++11 support was not explicitly requested. For example, install the svn2git port on El Capitan and observe that it is linked with libstdc++ instead of libc++:

$ otool -L /opt/local/bin/svn-all-fast-export
/opt/local/bin/svn-all-fast-export:
	/opt/local/lib/libsvn_fs-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libsvn_repos-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libapr-1.0.dylib (compatibility version 6.0.0, current version 6.2.0)
	/opt/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, current version 5.5.1)
	/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

This is weird and not the way other parts of MacPorts work. Ports built with Qt should respect the configure.cxx_stdlib variable like other ports do.

Change History (3)

comment:1 Changed 9 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Status: newassigned

As far as I can tell, the problem is -mmacosx-version-min=10.7 that qmake uses in CXXFLAGS and CFLAGS.
It seems to force the use of libstdc++.

Having qmake respect configure.cxx_stdlib might be a little difficult.
qmake seems to want its own ecosystem.

As soon as I get a little bit of time, I will see what I can do.

comment:2 Changed 9 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

Should be fixed in r144445.

comment:3 Changed 9 years ago by RJVB (René Bertin)

Didn't you set QMAKE_MACOSX_DEPLOYMENT_TARGET= in the configure.pre_args before? Was there a reason to move it from there to configure.args?

Qmake indeed seems to aim to deliver the user of having to specify the appropriate compiler and linker options. On OS X this goes so far as to invoke xcrun (and/or similar utilities) to determine where to find the toolchain. Getting qmake to respect configure.compiler (configure.cc, configure.cxx etc) isn't trivial at all in my experience.

Last edited 9 years ago by RJVB (René Bertin) (previous) (diff)
Note: See TracTickets for help on using tickets.