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

René J.V. Bertin rjvbertin at gmail.com
Thu Oct 6 09:25:15 PDT 2016


On Thursday October 06 2016 16:48:44 Mojca Miklavec wrote:

> This would probably mostly work fine if *all* ports were built with
> g++ (= against the same version of mp-provided stdlibc++). I can
> easily imagine problems when gcc is switched from, say, version 5 to
> version 6, but let's ignore that for a moment.

Actually, that hasn't yet caused me any problems on Linux. I've made the v6 collection the default as soon as it became available, and certainly haven't had to rebuild anything because of it.

Also, I never had compatibility issues on 10.6 when combining software built with the default compiler with software built with gcc 4.7, 4.8 or 4.9. Remember, 10.6 still used Apple's gcc 4.2 as the default compiler, and even the clang version provided by Xcode 4.something that was available briefly for 10.6 was crippled compared to gcc 4.2 (but admittedly faster).
Switching to MacPorts clang versions was possible but didn't really improve anything in terms of language support - it just made compile times much longer.

> Some of the ports that require C++11 currently blacklist all the gcc
> compilers and enforce libc++. Not because gcc would not be able to

If they do that via the cxx11 PortGroup as I'm beginning to guess, then getting around that block will be as easy as deactivating its payload ;)

> I'm not saying that this cannot work. Just that it calls for random
> headaches that one has to willingly accept and be able to fix on
> him/her own. (Or maintain a fork of MP with a monstrous amount of
> work.)

Isn't that more or less what running up-to-date software boils down to on 10.6? There may be central support for the libc++ manoeuvre, but you can't expect every port maintainer to be able (or even willing) to fix issues that arise regardless of having libc++ available.
I'm probably biased because I got sucked into this because of KDE, which led me to building (and adapting/evolving) more and more ports myself.

R.


More information about the macports-dev mailing list