<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I know it's not the party line, but IMHO to minimize hassles supporting these older systems we might well just flush them all to build everything with clang-4.0 or 5.0, to match the newer systems. Then most all systems would see similar or identical errors.</div><div><br></div><div> I'm not too clear on why it's worth effort to do otherwise. </div><div><br></div><div>K</div><div><br>On Nov 1, 2017, at 10:03 AM, David Strubbe <<a href="mailto:dstrubbe@macports.org">dstrubbe@macports.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><span style="font-size:12.8px">If the compilers need to be consistent, then you can use the compilers portgroup to enforce that.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 1, 2017 at 10:29 AM, Mojca Miklavec <span dir="ltr"><<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm currently trying to fix wxWidgets-3.0 in various ways. One of the<br>
problems of the latest release is that it compiles fine with both<br>
clang >= 500 and llvm-gcc. If I blacklist clang < 500 on Lion, it will<br>
fallback to llvm-gcc which works in principle, but I don't know<br>
whether it makes more sense to compile with, say, clang 3.4, or with<br>
llvm-gcc. Suggestions?<br>
<br>
The additional complication is that any port which builds against<br>
wxWidgets needs to use (more or less) the same compiler for both<br>
compiling wxWidgets and the port that depends on it. Add to that that<br>
ports that need both perl and wxWidgets probably need a compatible<br>
compiler for all three?<br>
<br>
If I just blacklist one compiler for wxWidgets (but not for the ports<br>
depending on it), I'll get a build failure on any other port that<br>
builds against it. That's partly because wxWidgets does some testing<br>
of compiler features and writes some of the results to the headers<br>
which are then included in the sources of dependent software. (I<br>
believe the reason for a failure of clang 425 on 10.7 is just some<br>
incorrectly implemented test, but I'm not too eager to debug that if I<br>
can simply switch the complier and get it working.)<br>
<br>
At least I'm sure that the build of dependent ports fails if wxWidgets<br>
is built with a more capable compiler. I'm not sure whether things<br>
work out of the box if one uses a less capable compiler for compiling<br>
wxWidgets and then some C++11 capable compiler for a dependent port,<br>
but I expect problems as well.<br>
<br>
What's the proper blacklisting? Since llvm-gcc-4.2 seems to work fine,<br>
I'm tempted to blacklist llvm-gcc just on Lion and newer, while<br>
letting 10.6 build with its default compiler (llvm-gcc). I didn't test<br>
10.6 yet though. Is that too weird? Does anyone have a better<br>
suggestion?<br>
<br>
Meanwhile I need to debug some weird side effects, like p5-wx trying<br>
to compile with<br>
/opt/local/clang++ -stdlib=libc++-mp-3.4<br>
for example. I didn't ask it to do anything like that.<br>
<br>
Thank you,<br>
Mojca<br>
</blockquote></div><br></div>
</div></blockquote></body></html>