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

[Lawrence Velázquez]

> On Oct 7, 2016, at 11:11 AM, René J.V. Bertin  wrote:
> 
> On Friday October 07 2016 10:51:59 Lawrence Velázquez wrote:
> 
>> Not to mention the fact that literally every single C++ port would have
>> to declare a library dependency on libgcc.
> 
> Or not: if a compiler selection mechanism is used that picks
> a macports-gcc version that dependency would be added indirectly, no?
> I'd find it more intuitive to invoke such a mechanism than declare
> a dependency on something we're used to take for granted...

Currently, if you set "configure.compiler macports-gcc-XYZ",
a dependency on gccXYZ is added automatically. A direct dependency on
libgcc is not added because we don't know what the port wants to use gcc
for. It currently works out because gcc* already depends on libgcc, but
the dependency tree is not actually correct.

The current mechanism for adding these dependencies is coarse. It
considers each of Clang / GCC / DragonEgg (RIP) to be a sort of compiler
collection and assumes that ports aren't going to mix and match. There
are many ports that do in fact mix and match (notably for Fortran), so
it might be useful to refine this mechanism to allow something like
"configure.compiler.cxx macports-gcc-XYZ", which would add a direct
library dependency on libgcc (among other things).

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Friday October 07 2016 10:51:59 Lawrence Velázquez wrote:

> Not to mention the fact that literally every single C++ port would have
> to declare a library dependency on libgcc.

Or not: if a compiler selection mechanism is used that picks a macports-gcc 
version that dependency would be added indirectly, no?
I'd find it more intuitive to invoke such a mechanism than declare a dependency 
on something we're used to take for granted...

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Lawrence Velázquez]

> On Oct 6, 2016, at 10:48 AM, Mojca Miklavec  wrote:
> 
> On 6 October 2016 at 16:23, René J.V. Bertin wrote:
>> 
>> Ken: apologies for not having thought of this, but myself when I was still 
>> running 10.6 I've had sufficient success with building C++11 code using a 
>> (then) recent gcc port.  It's possible that things have evolved so much 
>> nowadays that even that may not cut it anymore.
> 
> 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.
> 
> The problem is that MacPorts cannot easily support a zillion of
> different configurations and this is certainly an unsupported one.
> 
> 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
> build it, but to ensure at least some consistency. So if you want to
> use this configuration, you need quite a bit of editing of different
> ports, say goodbye to binary packages, expect other random problems.
> 
> 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.)

Not to mention the fact that literally every single C++ port would have
to declare a library dependency on libgcc.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Lawrence Velázquez]

> On Oct 6, 2016, at 12:49 PM, René J.V. Bertin  wrote:
> 
>> On Thursday October 06 2016 12:32:24 Brandon Allbery wrote:
>> 
>> now. At my previous job, when we ran into this we just lifted the whole
>> thing to glue multiple g++ releases to a common libstdc++ from Debian
>> (clang / libc++ wasn't an issue back then).
> 
> Sounds like something to be considered for the gcc ports, then ;)

All the gcc* ports (the recent ones, anyway) already use the single C++
support library installed by the libgcc port.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham Webuse]

On 2016-10-06, at 9:40 AM, René J.V. Bertin wrote:
> 
> Wow ... have you also thought about my mom's old blue baby iMac G3 which 
> still runs AFAIK? :D And maybe providing a newer Mach kernel for them, too?

Indeed, it's surprising to me as well sometimes just how useful these machines 
still are. MacPorts has proven to be very resilient over time, thanks to the 
efforts of many.

Just FYI, here's a list of the current ports one of my PPC tiger machines runs 
just at the moment... 700 installed ports, although some are duplicates / 
updates. And the DualG5s and DualG4s run these ports acceptably quickly. I 
think the PPC buildbot builds a very good % of the current Macports.



K

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Brandon Allbery]

On Thu, Oct 6, 2016 at 12:49 PM, René J.V. Bertin 
wrote:

> On Thursday October 06 2016 12:32:24 Brandon Allbery wrote:
> Hasn't this become easier at all?
>

Only if you can use the GPL3 libstdc++. Since the stuff Apple ships
doesn't, we lose. Linux of course does not have this problem.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 12:32:24 Brandon Allbery wrote:

Hasn't this become easier at all?

> now. At my previous job, when we ran into this we just lifted the whole
> thing to glue multiple g++ releases to a common libstdc++ from Debian
> (clang / libc++ wasn't an issue back then).

Sounds like something to be considered for the gcc ports, then ;)

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 09:26:43 Ken Cunningham Webuse wrote:

> 10.4 and 10.5 users who have PPC machines worth keeping might well have to 
> consider gcc cxx11options, if those systems are to have any path forward to 
> newer software.

Wow ... have you also thought about my mom's old blue baby iMac G3 which still 
runs AFAIK? :D And maybe providing a newer Mach kernel for them, too?

Frankly, I quickly reverted from 10.5 when I saw how much that hogged my PPC 
machines at the time, and I'd hate to keep fighting the uphill battle to do 
useful things with 10.4 . Not that it wasn't a great OS X version (I probably 
preferred it even over 10.6), but with Apple linking ObjC to the OS there's 
less and less "native" software that even builds on it. And if it's to run only 
cross-platform stuff under X11 (recent Qt versions being unlikely to build) you 
could just as well set up dual-boot and use the hardware under Linux or FreeBSD.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham Webuse]

On 2016-10-06, at 7:48 AM, Mojca Miklavec wrote:

> On 6 October 2016 at 16:23, René J.V. Bertin wrote:
>> 
>> Ken: apologies for not having thought of this, but myself when I was still 
>> running 10.6 I've had sufficient success with building C++11 code using a 
>> (then) recent gcc port.  It's possible that things have evolved so much 
>> nowadays that even that may not cut it anymore.
> 
> 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


10.6+ work great with libc++. I wouldn't feel a need to explore any other 
options. Just the binaries would help, once y'all decide how to name/specify 
them.

10.4 and 10.5 users who have PPC machines worth keeping might well have to 
consider gcc cxx11options, if those systems are to have any path forward to 
newer software. Jeremy has discussed this on a recent gtk3 ticket. It would not 
be expected to be part of the standard MacPorts process, as there is already 
plenty to do. A shadow repository for certain selected ports on these systems, 
such as the ones I've been building these past few months, would be the most 
likely way this would be implemented I think

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Brandon Allbery]

On Thu, Oct 6, 2016 at 12:25 PM, René J.V. Bertin 
wrote:

> 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.


You haven't seen the work distribution folks do to fit this stuff together.
They've been doing it since early versions of g++ where libstdc++ wasn't
even ABI compatible with *itself* across versions, so they're used to it by
now. At my previous job, when we ran into this we just lifted the whole
thing to glue multiple g++ releases to a common libstdc++ from Debian
(clang / libc++ wasn't an issue back then).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

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.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Mojca Miklavec]

On 6 October 2016 at 16:23, René J.V. Bertin wrote:
>
> Ken: apologies for not having thought of this, but myself when I was still 
> running 10.6 I've had sufficient success with building C++11 code using a 
> (then) recent gcc port.  It's possible that things have evolved so much 
> nowadays that even that may not cut it anymore.

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.

The problem is that MacPorts cannot easily support a zillion of
different configurations and this is certainly an unsupported one.

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
build it, but to ensure at least some consistency. So if you want to
use this configuration, you need quite a bit of editing of different
ports, say goodbye to binary packages, expect other random problems.

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.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 06:33:56 Ken Cunningham Webuse wrote:

> Some of the builds on these older machines can take hours and hours... 
> webkit2-gtk is not even to be mentioned.

Didn't even think of that yet, but yes. The problem is of course that we *are* 
indeed talking about older versions which may not justify spending exorbitant 
amounts of time and effort into coming up with an ideal solution.

Side-ways related: do we know how many of Apple's open-source libraries are 
based on C++ and could thus (potentially) be provided as libc++-based ports?

Ken: apologies for not having thought of this, but myself when I was still 
running 10.6 I've had sufficient success with building C++11 code using a 
(then) recent gcc port.  It's possible that things have evolved so much 
nowadays that even that may not cut it anymore.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ken Cunningham Webuse]

> 
> The only blocking stone is meeting the agreement about how to
> name the new binary archives [and implementing that] :)

It would be nice if that discussion was finalized and a plan enacted.

Some of the builds on these older machines can take hours and hours... 
webkit2-gtk is not even to be mentioned.

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Mojca Miklavec]

On 6 October 2016 at 15:08, Ryan Schmidt wrote:
>
> 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.

I must have confused something, sorry. Apparently only qt5-qtwebkit
includes PortGroup cxx11 1.0. I thought that the whole of Qt5 required
C++11, but I was wrong.

Some of the old posts (that probably kept me confused):
- https://lists.macosforge.org/pipermail/macports-dev/2015-December/031986.html
- https://lists.macosforge.org/pipermail/macports-dev/2015-December/031999.html
- https://lists.macosforge.org/pipermail/macports-dev/2015-December/031992.html

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 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  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

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

[Mojca Miklavec]

On 6 October 2016 at 14:40, René J.V. Bertin wrote:
> On Thursday October 06 2016 07:17:18 Ryan Schmidt wrote:
>
>> I don't understand... Those two paragraphs seem contradictory. You say it 
>> works without libc++, and that forcing libc++ would cause the ports to fail 
>> (on vanilla OS X < 10.9), but then you say it would help to use libc++.
>
> I guess that Mojca means that there will probably be less issues with Qt5 
> ports in general if we forced the use of libc++ across the board.

No, this is not what I was trying to say.

Pushing for libc++ would be a good idea anyway, but an independent
one. The only blocking stone is meeting the agreement about how to
name the new binary archives [and implementing that] :)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Mojca Miklavec]

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."
}

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> 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
c) does not provide any C++ libraries

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.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Oct 6, 2016, at 7:40 AM, René J.V. Bertin  wrote:
> 
>> We want to move the matter of determining that an error condition exists
>> from the portfiles and portgroups to MacPorts base. Then it will be easier
>> for the buildbot to query MacPorts base and ask if the port will be
>> installable, and skip it if not
> 
> I think we're not exactly thinking about the same things. I don't think you 
> can expect ports to know that without being able to include the PortGroups 
> they require. So even if the fundamental mechanism is part of the base layer 
> the error could still be determined in a PortGroup. And I think it'd make 
> sense if the cxx11 portgroup raised the "don't build" signal if it detects a 
> host that doesn't have libc++ installed.

I've explained the matter as best I can. You can refer to the mailing list 
archives for more details, specifically Clemens' explanation for why the matter 
must be handled by MacPorts base, not ports.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 07:17:18 Ryan Schmidt wrote:

> I don't understand... Those two paragraphs seem contradictory. You say it 
> works without libc++, and that forcing libc++ would cause the ports to fail 
> (on vanilla OS X < 10.9), but then you say it would help to use libc++.

I guess that Mojca means that there will probably be less issues with Qt5 ports 
in general if we forced the use of libc++ across the board.

> We want to move the matter of determining that an error condition exists
> from the portfiles and portgroups to MacPorts base. Then it will be easier
> for the buildbot to query MacPorts base and ask if the port will be
> installable, and skip it if not

I think we're not exactly thinking about the same things. I don't think you can 
expect ports to know that without being able to include the PortGroups they 
require. So even if the fundamental mechanism is part of the base layer the 
error could still be determined in a PortGroup. And I think it'd make sense if 
the cxx11 portgroup raised the "don't build" signal if it detects a host that 
doesn't have libc++ installed.

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Mojca Miklavec]

On 6 October 2016 at 14:17, Ryan Schmidt wrote:
>> On Oct 6, 2016, at 6:26 AM, Mojca Miklavec wrote:
>> On 6 October 2016 at 12:06, René J.V. Bertin wrote:
>>> On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote:
>>>
 If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.
>>>
>>> I wonder if that shouldn't simply be done by the Qt5 PortGroup then ...
>>>
>>> I don't really follow what that portgroup does. Is there a risk of breaking 
>>> anything when including it de-facto on 10.7+?
>>
>> qt5 (base and some other ports) still works on 10.7 without libc++
>> being set globally. If one would include the cxx11 portgroup, these
>> ports would fail to install as well.
>>
>> But it would probably help if you would use libc++ instead of libstdc++.
>
> I don't understand... Those two paragraphs seem contradictory. You say it 
> works without libc++, and that forcing libc++ would cause the ports to fail 
> (on vanilla OS X < 10.9), but then you say it would help to use libc++.

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).

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Oct 6, 2016, at 7:06 AM, René J.V. Bertin  wrote:
> 
> On Thursday October 06 2016 06:25:06 Ryan Schmidt wrote:
> 
>> By including the portgroup, you are declaring that the port requires C++11. 
>> Users using "vanilla" OS X versions prior to 10.9 who try to install such a 
>> port will receive an error message with a link to the wiki page explaining 
>> how to reconfigure their systems for libc++. 
> 
> Right. I always forget which version got libc++ by default (I skipped 10.7 
> and 10.8 myself so never had to deal with the situation).
> 
>> This is an extremely invasive procedure for users so (obviously!) do not 
>> include the portgroup in ports that do not require C++11. 
> 
> Agreed. Sadly it isn't always trivial to figure out which code really needs 
> it, other than waiting for errors like the one I received.
> 
>> We would have to write the code to do that. We have not yet done so.
> 
> How do the bots decide not to build ports for which licensing makes binary 
> redistribution "impossible"? Is that also handled by raising an error?

But the bots do build ports that aren't distributable. They just don't 
distribute the binaries they built. The buildbot exists not only for the 
production and distribution of binaries, but also for developers to know that 
their ports build successfully.

>> Ideally, this would involve changes to MacPorts base so that a port could 
>> indicate what systems it can or cannot install on. MacPorts base doesn't yet 
>> have that capability. 
> 
> Something that doesn't involve raising an error you mean?
> Although, the easiest way to implement this would probably be through a 
> predefined error return code which could then be handled differently on user 
> systems and on the build bots.

I mean that the error that gets raised is not raised by MacPorts base. It's 
raised by a portgroup, which is included from a portfile. We want to move the 
matter of determining that an error condition exists from the portfiles and 
portgroups to MacPorts base. Then it will be easier for the buildbot to query 
MacPorts base and ask if the port will be installable, and skip it if not. 
Currently, MacPorts base does not know whether a port would be installable, 
until it tries to install it. We currently have no way to differentiate between 
expected errors (e.g. this port does not work on this Mac OS version) which we 
don't want the buildbot to notify us about, and unexpected errors (e.g. this 
port failed to compile) which we do want to know about.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Oct 6, 2016, at 6:26 AM, Mojca Miklavec  wrote:
> 
> On 6 October 2016 at 12:06, René J.V. Bertin  wrote:
>> On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote:
>> 
>>> If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.
>> 
>> I wonder if that shouldn't simply be done by the Qt5 PortGroup then ...
>> 
>> I don't really follow what that portgroup does. Is there a risk of breaking 
>> anything when including it de-facto on 10.7+?
> 
> qt5 (base and some other ports) still works on 10.7 without libc++
> being set globally. If one would include the cxx11 portgroup, these
> ports would fail to install as well.
> 
> But it would probably help if you would use libc++ instead of libstdc++.

I don't understand... Those two paragraphs seem contradictory. You say it works 
without libc++, and that forcing libc++ would cause the ports to fail (on 
vanilla OS X < 10.9), but then you say it would help to use libc++.


>>> Until we figure out how to prevent it, you'll still receive failure 
>>> notifications from non-libc++ buildbot workers about that.
>> 
>> Surely there must be a way to tell the bots not to bother trying to build a 
>> given port, which would (or could) trickle upwards to all dependencies that 
>> require the port installed for building?
> 
> There's probably a ticket for that somewhere. If not a ticket, there
> was at least a thread on the devel mailing list.

Yes we've discussed on the mailing list but I did not find a ticket for it.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 06:25:06 Ryan Schmidt wrote:

> By including the portgroup, you are declaring that the port requires C++11. 
> Users using "vanilla" OS X versions prior to 10.9 who try to install such a 
> port will receive an error message with a link to the wiki page explaining 
> how to reconfigure their systems for libc++. 

Right. I always forget which version got libc++ by default (I skipped 10.7 and 
10.8 myself so never had to deal with the situation).

>  This is an extremely invasive procedure for users so (obviously!) do not 
> include the portgroup in ports that do not require C++11. 

Agreed. Sadly it isn't always trivial to figure out which code really needs it, 
other than waiting for errors like the one I received.

> We would have to write the code to do that. We have not yet done so.

How do the bots decide not to build ports for which licensing makes binary 
redistribution "impossible"? Is that also handled by raising an error?

> Ideally, this would involve changes to MacPorts base so that a port could 
> indicate what systems it can or cannot install on. MacPorts base doesn't yet 
> have that capability. 

Something that doesn't involve raising an error you mean?
Although, the easiest way to implement this would probably be through a 
predefined error return code which could then be handled differently on user 
systems and on the build bots.

R.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Mojca Miklavec]

On 6 October 2016 at 12:06, René J.V. Bertin  wrote:
> On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote:
>
>> If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.
>
> I wonder if that shouldn't simply be done by the Qt5 PortGroup then ...
>
> I don't really follow what that portgroup does. Is there a risk of breaking 
> anything when including it de-facto on 10.7+?

qt5 (base and some other ports) still works on 10.7 without libc++
being set globally. If one would include the cxx11 portgroup, these
ports would fail to install as well.

But it would probably help if you would use libc++ instead of libstdc++.

>> Until we figure out how to prevent it, you'll still receive failure 
>> notifications from non-libc++ buildbot workers about that.
>
> Surely there must be a way to tell the bots not to bother trying to build a 
> given port, which would (or could) trickle upwards to all dependencies that 
> require the port installed for building?

There's probably a ticket for that somewhere. If not a ticket, there
was at least a thread on the devel mailing list.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

On Oct 6, 2016, at 05:06, René J.V. Bertin  wrote:
> 
>> On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote:
>> 
>> If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.
> 
> I wonder if that shouldn't simply be done by the Qt5 PortGroup then ...
> 
> I don't really follow what that portgroup does. Is there a risk of breaking 
> anything when including it de-facto on 10.7+?

By including the portgroup, you are declaring that the port requires C++11. 
Users using "vanilla" OS X versions prior to 10.9 who try to install such a 
port will receive an error message with a link to the wiki page explaining how 
to reconfigure their systems for libc++. (The buildbot workers, being nothing 
more than users who install ports, will receive the same error.) This is an 
extremely invasive procedure for users so (obviously!) do not include the 
portgroup in ports that do not require C++11. 


>> Until we figure out how to prevent it, you'll still receive failure 
>> notifications from non-libc++ buildbot workers about that.
> 
> Surely there must be a way to tell the bots not to bother trying to build a 
> given port, which would (or could) trickle upwards to all dependencies that 
> require the port installed for building?

We would have to write the code to do that. We have not yet done so.

Ideally, this would involve changes to MacPorts base so that a port could 
indicate what systems it can or cannot install on. MacPorts base doesn't yet 
have that capability. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[René J . V . Bertin]

On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote:

> If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.

I wonder if that shouldn't simply be done by the Qt5 PortGroup then ...

I don't really follow what that portgroup does. Is there a risk of breaking 
anything when including it de-facto on 10.7+?

> Until we figure out how to prevent it, you'll still receive failure 
> notifications from non-libc++ buildbot workers about that.

Surely there must be a way to tell the bots not to bother trying to build a 
given port, which would (or could) trickle upwards to all dependencies that 
require the port installed for building?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Oct 6, 2016, at 3:56 AM, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I got the attached build failure notifications, which in both cases I think 
> can be traced to the use of `-stdlib=libstdc++` :
> 
> {{{
> [ 84%] Building CXX object src/CMakeFiles/dbusmenu-qt5.dir/utils.cpp.o
> cd 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/build/src
>  && 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>-DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB 
> -Ddbusmenu_qt5_EXPORTS -iframework /opt/local/libexec/qt5/lib -isystem 
> /opt/local/libexec/qt5/lib/QtWidgets.framework/Headers -isystem 
> /opt/local/libexec/qt5/lib/QtGui.framework/Headers -isystem 
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers -isystem 
> /opt/local/libexec/qt5/./mkspecs/macx-clang -isystem 
> /System/Library/Frameworks/OpenGL.framework/Headers -isystem 
> /opt/local/libexec/qt5/lib/QtDBus.framework/Headers 
> -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/libdbusmenu-qt-0.9.3.15.10/src
>  
> -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/build/src
>   -pipe -Os -stdlib=libstdc++  -fvisibility=hidden -Woverloaded-virtual -Wall 
> -std=c++11 -DNDEBUG -arch x86_64 -mmacosx-version-min=10.8 -fPIC   -fPIC -o 
> CMakeFiles/dbusmenu-qt5.dir/utils.cpp.o -c 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/libdbusmenu-qt-0.9.3.15.10/src/utils.cpp
> In file included from 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/libdbusmenu-qt-0.9.3.15.10/src/dbusmenuexporterdbus_p.cpp:21:
> In file included from 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/libdbusmenu-qt-0.9.3.15.10/src/dbusmenuexporterdbus_p.h:25:
> In file included from 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_dbusmenu-qt/dbusmenu-qt5/work/libdbusmenu-qt-0.9.3.15.10/src/dbusmenutypes_p.h:25:
> In file included from 
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers/QList:1:
> In file included from 
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qlist.h:41:
> In file included from 
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qhashfunctions.h:39:
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qpair.h:62:44: error: no 
> member named 'declval' in namespace 'std'
>Q_DECL_NOEXCEPT_EXPR(noexcept(std::declval() = p.first) && 
> noexcept(std::declval() = p.second))
>  ~^
> /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qcompilerdetection.h:1042:43:
>  note: expanded from macro 'Q_DECL_NOEXCEPT_EXPR'
> # define Q_DECL_NOEXCEPT_EXPR(x) noexcept(x)
> }}}
> 
> I'm a bit surprised that this happens on 10.8 . What can be done about it - 
> include the cxx11 PortGroup or something else?

If a port requires C++11 / libc++, include the cxx11 1.0 portgroup.

Until we figure out how to prevent it, you'll still receive failure 
notifications from non-libc++ buildbot workers about that.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev