all compilers blacklisted or unavailable

Wed Mar 22 10:51:20 UTC 2017

Jeremy, I'm Cc'ing you for input on wavpack; see the last few paragraphs.

On Mar 21, 2017, at 03:37, Jan Stary wrote:

> This is MacPorts 2.4.1 on MacOSX 10.6.8.
> A build of audio/sox starts with the following warning:
> 
> $ sudo port install -d sox

Note that this "-d" does nothing. Single-letter flags like "-d" are global flags and only take effect when placed after the word "port" and before the action verb, e.g. "sudo port -d install sox". Multi-letter flags like "--enforce-variants" apply only to specific verbs, so they only take effect if you place them after the verb, e.g. "sudo port upgrade --enforce-variants someport +x11".

> Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
> Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
> --->  Computing dependencies for sox
> --->  Fetching archive for sox
> --->  Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from https://packages.macports.org/sox
> --->  Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from http://nue.de.packages.macports.org/sox
> --->  Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from http://lil.fr.packages.macports.org/sox
> --->  Fetching distfiles for sox
> --->  Verifying checksums for sox
> --->  Extracting sox
> --->  Applying patches to sox
> --->  Configuring sox
> --->  Building sox
> --->  Staging sox into destroot
> --->  Installing sox @14.4.2_0
> --->  Activating sox @14.4.2_0
> --->  Cleaning sox
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  No broken files found.
> 
> What "all compilers" are those? (I have Xcode 3.2.6)

All compilers that are in the list of compilers that MacPorts will consider to build the port in question. It depends on the Xcode version and the macOS version and ports can modify the list if needed. It usually includes the version of clang provided by Xcode and newer versions of clang provided by MacPorts. With Xcode 4 and earlier, it also includes llvm-gcc-4.2, and with Xcode 3 and earlier, it also includes gcc-4.2. You can see the code that builds the default list here:

https://github.com/macports/macports-base/blob/v2.4.1/src/port1.0/portconfigure.tcl#L474

> Why are they blacklisted? Who blacklisted them?

The author of the portfile determined that those compilers were unable to build this port.

> Why are they unavailable? The gcc and clang from Xcode work just fine.

There are a wide variety of reasons why code written for today's compilers might not work on last decade's compilers. As was mentioned, in some cases you can find a comment in the portfile that explains why a compiler is blacklisted. In other cases, you may have to go to the git history and read the commit message that added the blacklisting.

> How do I get port(1) to print all this for me if -d doesn't?

Using the debug flag properly (sudo port -d install sox) will give you the context to see which port is causing this warning, but it won't explain the reasons for the blacklisting; for that you'll have to explore the code.

> WHy is the message printed twice?

MacPort apparently evaluates this information twice for each port. I don't know why. Perhaps there is an opportunity for optimization here.

As Daniel pointed out, the message applies not to sox itself but to its dependencies. (There's no way to know that by looking at the non-debug output, but after analysis, that's what's happening.) Even though you already have the dependencies installed, MacPorts will still evaluate the dependencies' portfiles and report any problems it runs into.

Looking at all of sox's recursive dependencies, I see four ports that blacklist specific compilers:

flac blacklists Xcode clang < 503 and MacPorts clang 3.3. The reason given in the Portfile is https://trac.macports.org/ticket/46038. You're on Snow Leopard where the default compiler is gcc-4.2 so that compiler will still get used.

gettext blacklists Xcode clang < 211.10.1. The reason given is https://trac.macports.org/ticket/31167. Same as above, this doesn't mention gcc-4.2, so that still gets used on your system.

libopus, on Intel systems, blacklists Xcode clang < 500 and all Xcode gcc compilers. The reason given is an error message "checking How to get X86 CPU Info... configure: error: no supported Get CPU Info method, please disable intrinsics". On your system, this means MacPorts clang 3.4 will get used.

wavpack blacklists Xcode clang < 500, MacPorts clang 3.3 and 3.4, and all Xcode gcc compilers. This covers all of the compilers in the list on your system, hence the message that all compilers are blacklisted. When this happens, MacPorts prints the warning and then tries to build the port using the first compiler in the list, knowing that it will fail.

No reason is given in the portfile, but looking at the git history, we see that wavpack used to disable its assembly code on Snow Leopard and earlier because the compilers couldn't handle it. Then, when build problems were discovered on Lion, this was changed to reenable the assembly code but blacklist the old compilers that couldn't handle it:

https://github.com/macports/macports-ports/commit/0090d5f7bae96c92d19d297e955fb203e3231a41

Then it was discovered that the port failed to build on Leopard (and presumably Snow Leopard) because all compilers were blacklisted:

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

Jeremy initially considered adding newer MacPorts clang compilers to the fallback list, but thought this would have adverse consequences (a dependency on libc++), so instead he did something which I don't think I've seen done in any other port: he wrote code to detect if all compilers are blacklisted, and if so, disable assembly again:

https://github.com/macports/macports-ports/commit/6fb35a1f2843454f08ef5027dfe0e3db59016d99

In this way, the faster assembly code could be used if a compiler that understands it is found, otherwise assembly is disabled and the port can still build.

This is clever, but I don't like that it causes MacPorts to print an inaccurate warning that clearly causes user confusion. I think we could fix the problem by having the port blacklist the compilers only when libc++ is in use (MacPorts base will then add newer clang compilers to the fallback list), and disable assembly when libstdc++ is in use.