Blacklisting gcc

[Ryan Schmidt]

On Mar 27, 2018, at 06:41, Mojca Miklavec wrote:

> On 27 March 2018 at 08:31, Ryan Schmidt wrote:
>> 
>>> On Mar 26, 2018, at 01:25, Mojca Miklavec wrote:
>>>> On 26 March 2018 at 02:49, Ryan Schmidt wrote:
>>>>> On Mar 25, 2018, at 14:37, David B. Evans wrote:
>>>>> 
>>>>>> +# blacklist compilers that do not support C11 (redefinition of typedef ‘GtkSourceTag’ at gtksourceview/gtksourcetag.h:35)
>>>>>> +compiler.blacklist  *gcc* {clang < 300}
>>>>> 
>>>>> Please be more specific here, such as "*gcc-3.* *gcc-4.*". Newer versions of gcc do support C11, and a change was already committed to MacPorts base which will let PowerPC systems fall back to gcc6 instead of clang (since clang doesn't work on PowerPC). Other ports may need more-specific blacklists too.
>>>> 
>>>> Is there any chance to implement something like
>>>>  compiler.blacklist {gcc < 4.7} {macports-clang < 3.7}
>>>> ?
>> 
>> There is no code currently written that would allow that to work. If we were to add code to the compilers_blacklist_versions for that, how should it work?
> 
> I don't know how the current implementation works, but from the
> functional point of view ...
> 
>> Currently, the above line would mean "blacklist versions of the compiler named 'gcc' that are earlier than 4.7" and "blacklist versions of the compiler named 'macports-clang' that are earlier than 3.7". There are no compilers in MacPorts named "gcc" or "macports-clang" so these statements would currently have no effect. Are you proposing that the names "gcc" and "macports-clang" be special-cased in the portgroup, and taken to mean "the set of ports whose names start with 'gcc'" (or maybe even "...whose names contain 'gcc'"?) and "the set of ports whose names start with 'macports-clang'"? That's a plausible solution, I'm just pointing out that it would be special-case code.
> 
> Yes, that's the meaning that I would like to convey through that syntax.

I can understand that. But I just want to make sure you understand that's not at all what the portgroup currently does.

Currently, it examines each item of compiler.blacklist. If the item is a single word, such as *gcc-4.*, it is skipped; MacPorts base will do the actual blacklisting of that compiler later. If the item has more than one word, such as {clang < 500} (3 words), it takes the first word (in this example "clang") as the MacPorts compiler name. It asks MacPorts what the executable name is for that compiler name, then it runs that executable with the "-v" flag, which causes the compiler to print its version number and other information. For each compiler the portgroup knows about (clang, apple-gcc-4.2, llvm-gcc-4.2, gcc-4.2, gcc-4.0), it knows how to extract the version number and build number from the "-v" output using a regular expression. Then, until there are no more words in this compiler blacklist value, it gets the next two words (in this example "< 500") and performs that numeric comparison against the compiler's actual version. If it matches, then the compiler is to be blacklisted, and the compiler name by itself ("clang") is added to compiler.blacklist, so that MacPorts base will blacklist it.


> The list for {gcc < 4.7} should cover (using
> https://trac.macports.org/wiki/UsingTheRightCompiler as reference):
> - apple-gcc-4.[02]
> - gcc-3.3
> - gcc-4.[02]
> - llvm-gcc-4.2
> - macports-gcc-4.[3456]
> - macports-llvm-gcc-4.2
> - macports-dragonegg-3.[45]-gcc-4.[56]
> 
> List of problematic compilers which should probably always be blacklisted :)
> - cc
> - gcc (/usr/bin/gcc)
> - macports-gcc

"Always blacklisted" makes no sense. If those compiler should never be used, they should not be in the fallback list in the first place. You can check portconfigure.tcl to see if they're in the list, and if so, you can discover why by looking at the blame output.


> For macports-clang I would have suggested using {clang < 3.7}, but
> that one has already been taken :)

There is another proposal which is that when we blacklist Xcode clang using e.g. {clang < 500}, then the portgroup should automatically add to the list the MacPorts clang version(s) that correspond to that Xcode clang blacklist. The only problem with that proposal is that we don't have a list that correlates those versions numbers.

https://trac.macports.org/ticket/56093