<div dir="ltr">Wow so many choices :/<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 8, 2015 at 3:08 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Saturday February 07 2015 20:11:25 Jeremy Whiting wrote:<br>
<br>
>Ok, googling showed me this:<br>
><a href="https://trac.macports.org/browser/trunk/dports/lang/hugs98/files/patch-packages-base-include-HsBase.h.diff?rev=81676" target="_blank">https://trac.macports.org/browser/trunk/dports/lang/hugs98/files/patch-packages-base-include-HsBase.h.diff?rev=81676</a><br>
>which fixes kio also. Does it make sense to check that into kio itself with<br>
<br>
</span>It's quite possible that that's the same fix I already had to apply at some time in the past. Makes sense, right - you get a complaint about a symbol that clearly is "standard" and should be a global ... try declaring it extern with the appropriate type and see how that goes :)<br>
<br>
Reminds me of a C++11 specific typedef that was missing in clang 3.5 until not so long ago; this kind of issue is probably due to an oversight from the compiler developers.<br></blockquote><div><br></div><div>After reading man environ on both systems I've submitted a review request that builds on both machines also <a href="https://git.reviewboard.kde.org/r/122481/">https://git.reviewboard.kde.org/r/122481/</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
>an #ifdef Q_OS_MAC, or is that not needed anymore on "modern" OS X? I'll<br>
<br>
</span>It would be cleaner to put it in a block that depends on the OS X version (you'll need AvailabilityMacros.h for that).<br>
<br>
As to C++11:<br>
<span class="">> another problem, apparently std doesn't have lround which kdeclarative uses<br>
> :/. Apparently it's from C++11, is there a C++11 standard library on OSX<br>
> Lion or is that too old of a system to have such a new set of libraries?<br>
<br>
</span>I keep to my personal rule of thumb that C++11 support isn't complete in clang on pre-10.8 or 10.9 systems because it depends on system headers, but the situation is more subtle than that IIRC. On 10.6.8 I came to the conclusion that it was better to use configure.compiler=macports-gcc-4.9 at once when I noticed the use of C++11. That's how I could build KDevelop 4.7 . It's not guaranteed NOT to lead to conflicts but in practice that never happened to me.<br></blockquote><div><br></div><div>What compiler is used by macports, or is that configurable by the end user? Another idea I have is could we ifdef for C++11 support and use Qt::round or something else when C++11 isn't available on a give platform? Is there something we could #ifdef on to get that? iirc KDE Applications can opt to use C++11 if they want, but I thought it wasn't permitted in libraries (so this use in kdeclarative maybe should get removed anyway, not sure.) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On a side-note: using gcc also gave a nice and useful speed boost. I think I've recently provided some evidence that even on 10.9 macports-clang-3.5 is slower (just 2x or so) than the almost identical AppleClang version; on 10.6 and presumably 10.7 you don't have that choice but FOSS gcc ought to be perfectly usable as long as you don't require Apple specific features.<br>
Note that by using a dev. compiler version you're exposing yourself to unforeseen issues but also to the fact that MacPorts builds it (and version 3.6. too, I think, still) with assertions enabled, which degrades performance even more.<br>
<br>
As to performance: clang does have a nice feature in that it's inherently a cross-compiler that can generate code for different targets. On OS X, it can also generate gnu-linux object code, and on Linux it can also generate mach-o object codes. Setting it up for use with distcc in a heterogenous cluster is thus a matter of writing a few wrappers that add the appropriate output option, and figuring out how MacPorts' support for distcc works.<br>
Sadly that won't help if you have a C++11 problem...<br></blockquote><div><br></div><div>Cross compling and using distcc may be interesting in the future, first I'd like to get everything to build on the platforms I have though.</div><div><br></div><div>thanks,</div><div>Jeremy </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
R.<br>
_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a><br>
</div></div></blockquote></div><br></div></div>