Question about compiler blacklisting (llvm-gcc for wxWidgets)

[Mojca Miklavec]

On 2 November 2017 at 12:01, Ryan Schmidt wrote:
> On Nov 1, 2017, at 11:29, Mojca Miklavec wrote:
>
>> I'm currently trying to fix wxWidgets-3.0 in various ways. One of the
>> problems of the latest release is that it compiles fine with both
>> clang >= 500 and llvm-gcc. If I blacklist clang < 500 on Lion, it will
>> fallback to llvm-gcc which works in principle, but I don't know
>> whether it makes more sense to compile with, say, clang 3.4, or with
>> llvm-gcc. Suggestions?
>>
>> The additional complication is that any port which builds against
>> wxWidgets needs to use (more or less) the same compiler for both
>> compiling wxWidgets and the port that depends on it. Add to that that
>> ports that need both perl and wxWidgets probably need a compatible
>> compiler for all three?
>>
>> If I just blacklist one compiler for wxWidgets (but not for the ports
>> depending on it), I'll get a build failure on any other port that
>> builds against it. That's partly because wxWidgets does some testing
>> of compiler features and writes some of the results to the headers
>> which are then included in the sources of dependent software. (I
>> believe the reason for a failure of clang 425 on 10.7 is just some
>> incorrectly implemented test, but I'm not too eager to debug that if I
>> can simply switch the complier and get it working.)
>>
>> At least I'm sure that the build of dependent ports fails if wxWidgets
>> is built with a more capable compiler. I'm not sure whether things
>> work out of the box if one uses a less capable compiler for compiling
>> wxWidgets and then some C++11 capable compiler for a dependent port,
>> but I expect problems as well.
>
> That sounds terrible. If this is true, then I think you should bring this to the attention of the wxWidgets developers and explain to them that this is not usable. It's just not possible to guarantee that all ports that want to use wxWidgets will be compatible with the same compiler. Sometimes there are compiler bugs that affect some projects, and sometimes projects contain code errors that certain compilers won't allow. We need the freedom to be able to impose compiler blacklist on a port by port basis.
>
> Fortunately, you already have the wxWidgets-1.0 portgroup, which all ports which use wxWidgets are supposed to use, so you could impose any needed blacklisting there, but that won't help you if the compiler choice needs to be imposed on perl ports as well. I'm not clear why that would be needed though.
>
> What kind of errors do you see when you try to mix compilers?

I can try to give you a more accurate description later by actually
trying to recompile some stuff.

But generally the problems fall into some very similar category as
mix-and-matching C++11 and pre-C++11 compilers. The wxWidgets does all
kinds of build-time testing for various features and then remembers
the results in some equivalent of config.h file. That file is then
loaded when compiling dependent ports. For example, if you build
wxWidgets with some "almost C++11" compiler which knows about
"tr1/somelibrary" (known as "somelibrary" under C++11) and then
compile a dependent port with C++11, it will try to search for
"tr1/somelibrary" again and fail. If you build with some ancient
compiler like gcc-4.2, it will also fail to find "tr1/somelibrary".

You could argue this is "terrible", but the situation is similarly
"terrible" with other ports requiring C++11 on older systems. I could
try to come up with a more precise analysis. I think that wxWidgets
does some wrapping of certain functions, so that you can do certain
stuff with, say, strings, that are not supported by older compilers
(in which case wxWidgets provides implementation for you to achieve
that goal easily), while the features of the new compilers would be
used when available. I'm not 100% sure, but that was my impression.
This simplifies the work for app developers, so that they don't need
to make a zillion feature tests themselves.

>> What's the proper blacklisting? Since llvm-gcc-4.2 seems to work fine,
>> I'm tempted to blacklist llvm-gcc just on Lion and newer, while
>> letting 10.6 build with its default compiler (llvm-gcc). I didn't test
>> 10.6 yet though. Is that too weird? Does anyone have a better
>> suggestion?
>
> So wait, llvm-gcc-4.2 works, but gcc-4.2 does not?

I didn't (intend to) say that. Lion's built-in clang (425) doesn't
work, but llvm-gcc-4.2 does. I didn't even try with gcc 4.2. Maybe
I'll try to install a VM with 10.6 and test there. Initially I
switched to clang 3.4 and then ended up with problems compiling
dependent applications. I only ended up building with llvm-gcc by pure
accident and I was surprised to figure out that it worked just fine.

I suspect that's because one feature test is incomplete. It figures
out that compiler can do A and then assumes it can do B as well (which
it can't). If gcc cannot do A, it doesn't even attempt to use B.

>> Meanwhile I need to debug some weird side effects, like p5-wx trying
>> to compile with
>>    /opt/local/clang++ -stdlib=libc++-mp-3.4
>> for example. I didn't ask it to do anything like that.
>
> Yeah that looks wrong! I wonder why it's doing that.

I need to invest more time into it. (I was travelling for a long time
and just came back, having to catch up with various things ...)


As for the other compiler-related questions: that's an interesting
topic, but let's fork the discussion (I'm super interested in
discussing that as well, just not with respect to wx). Also, I cannot
wait for that other question to be resolved, I need to fix wxWidgets
sooner that we would be able to get infrastructure for bootstrapping
for the latest clang ready.

Mojca