> On Mar 22, 2017, at 03:51, Ryan Schmidt <ryandes...@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
smime.p7s
Description: S/MIME cryptographic signature
