> On Oct 6, 2016, at 7:55 AM, Mojca Miklavec <mo...@macports.org> wrote: > > On 6 October 2016 at 14:43, Ryan Schmidt wrote: >>> On Oct 6, 2016, at 7:35 AM, Mojca Miklavec wrote: >>> >>> It works without https://trac.macports.org/wiki/LibcxxOnOlderSystems >>> (= setting libc++ to become your default stdlib globally). But the >>> port in question most likely still needs libc++. >>> >>> Read as: if you use the cxx11 PortGroup and use a default installation >>> of MacPorts, the port won't compile. But you can still require libc++ >>> for this individual port and it might compile and work. >>> >>> Using the cxx11 PortGroup is desired/absolutely needed when a port has >>> many dependencies that need a compatible stdlib as the app would crash >>> otherwise. It is not needed for "standalone" apps that don't need to >>> communicate to their dependencies via some C++ API (or when >>> dependencies use the same stdlib, like qt5 which switched to libc++ >>> anyway). >> >> You're right. You should only force libc++ (without using the cxx11 >> portgroup) if the port >> >> a) requires C++11 (or for some other reason requires libc++), and >> b) does not depend on any C++ libraries, and > > Generally true. But this can be relaxed a bit: "or if dependent > libraries with C++ api are also guaranteed to use libc++". > >> c) does not provide any C++ libraries > > Are you talking about the PortGroup (like the qt5 PortGroup) or about > individual ports? > > In case of the latter: why is this relevant for the port in question? > Doesn't that only affect dependent ports? And dependent ports don't > know that their dependency included the c++11 PortGroup. > >> Is that the case for Qt5? It is the case for mongodb, so I've done it there. >> Qt5 provides tons of libraries that other programs are expected to use, and >> they seem to link to the C++ library, so I don't think we can just force Qt5 >> to libc++ and hope things will work; they won't. > > One case of a problematic port is gnuplot. If one wants to use Qt5 > (which is optional and disabled by default), gnuplot has to be > compiled with libc++, but then wxWidgets should either not be enabled > or it should be compiled against libc++ too. I simply didn't add that > complex logic into the Portfile. > > All I did was a lame warning (but luckily not many people bother > installing the qt5 variant, or at least not users of legacy systems): > > variant qt5 conflicts qt description "Enable qt terminal with Qt 5" { > if { ${configure.cxx_stdlib} ne "libc++" } { > ui_warn "Gnuplot should be compiled against libc++ if you want > to use Qt 5." > }
Let's take the qt5-qtbase port as an example. It depends on the icu port. Its library /opt/local/libexec/qt5/lib/QtCore.framework/QtCore links with icu's libraries /opt/local/lib/libicui18n.55.dylib, /opt/local/lib/libicuuc.55.dylib, /opt/local/lib/libicudata.55.dylib, and also (on my El Capitan system) /usr/lib/libc++.1.dylib. If we force qt5-qtbase to use libc++, it will link with libc++ even on vanilla OS X 10.7 and 10.8 systems. Icu's /opt/local/lib/libicui18n.55.dylib and /opt/local/lib/libicuuc.55.dylib libraries also link (on my El Capitan system) with /usr/lib/libc++.1.dylib. On vanilla 10.7 and 10.8, it would link with libstdc++ instead. Does QtCore pass C++ objects to libicui18n or libicuuc? I don't know. If it does, that won't work if the C++ libraries are mismatched. ~ Let's take another example, the luminance-hdr port. It uses the qt5 portgroup and depends on qt5-qtbase, so you would say it should force libc++. But it also depends on boost, which on vanilla 10.7 and 10.8 is built using libstdc++. Does luminance-hdr use both Qt5 and boost C++ objects? If so, that can't work with different C++ libraries. ~ The above are examples of the reasons why the choice of C++ library has to happen for the MacPorts collection as a whole, not for individual ports when they are intermingled with one another, and why we have the instructions on the LibcxxOnOlderSystems page. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
