> 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

Reply via email to