dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

[Ryan Schmidt]

> On Oct 6, 2016, at 7:55 AM, Mojca Miklavec <mojca at 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.