all compilers blacklisted or unavailable

Wed Mar 22 15:27:12 UTC 2017

> On Mar 22, 2017, at 03:51, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 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.

Yeah.  I agree this is a messy, sub-optimal hack.

To github.com:macports/macports-ports.git
  2cfee4d8ed..9fd4dd6a95  master -> master

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170322/7b1bcf3c/attachment.bin>