Compilers and Variants and Architectures Oh My!

[Ryan Schmidt]

On Mar 24, 2013, at 12:53, Peter Johansson wrote:

> Greetings all!  I am new to this mailing list but not MacPorts.  I
> have been using it for about six years now, mostly for small command
> line apps -  wget, sox, things of that nature.  Somewhat recently I
> started using it for larger tools like Wine and gerbv.  While I had
> some minor problems, I was able to build what I needed without much
> difficulty.

Welcome to the list!


> I recently upgraded my machine (yes, the same one I bought six+ years
> ago) with a SSD, and took the opportunity for a completely fresh
> re-install.  I am still running Snow Leopard but I upgraded to the
> latest XCode for SL, XCode 4.2.  This caused a bunch of problems which
> I eventually tracked down to a problem with the clang compiler shipped
> with XCode 4.2 -- it does not properly respect CPATH causing a whole
> bunch of things to fail.  In the process of building a working system,
> I got sucked into a little more of the nitty gritty than I had hoped.

Yes, that's correct, old versions of clang (those in Xcode 4.3.x and earlier, as I recall) do not honor CPATH, and this is often a problem.


> Although I have read the page "Using the Right Compiler" this page
> does not actually provide any insight as to which compiler should be
> used to build the MacPorts tree, particularly on older systems with
> rather outdated system compilers.  It seems as if MacPorts prefers
> clang, but by default it uses your system's default clang. While this
> is probably best if you are running the latest XCode, this is clearly
> not optimal if you are limited to an older version of XCode.

MacPorts chooses the default compiler based on the Xcode version:

For Xcode 2.x (Tiger) and Xcode 3.0.x and 3.1.x (Leopard) the default is gcc-4.0.
For Xcode 3.2.x (Snow Leopard) the default is gcc-4.2.
For Xcode 4.0.x (Snow Leopard) and 4.1.x (Snow Leopard and Lion) the default is llvm-gcc-4.2.
For Xcode 4.2.x and above (Snow Leopard and later) the default is clang.

Xcode 4.2.x and above no longer include any version of gcc. And it has been announced in the Xcode 4.6 release notes that it is the last version that will include llvm-gcc, leaving only clang going forward. We know that Apple believes llvm and clang are the future of compiling on OS X, which is why we began pushing toward this in the default compiler selection.

However, as you discovered, the by now quite old versions of clang in Xcode 4.2.x and earlier have some deficiencies compared with current versions.

The problem is worsened by the fact that Xcode 4.2.x is not in very common use. Xcode 4 for Snow Leopard is not available for free; you can only get it if you have a paid Apple Developer account. And on Lion, users are upgrading to the latest version, 4.6.1. So by using Xcode 4.2 you're likely to encounter problems others haven't encountered and will have difficulty reproducing and fixing.

Additional problems can occur for Xcode 4.2 users on Snow Leopard who already built some ports while using Xcode 3.2.x, or who get binaries from our build server, which uses Xcode 3.2.6. A few ports keep track of what compiler was used to compile them, and try to enforce the use of that compiler for related ports. This can be a problem if, for example, you install a port X with Xcode 3.2.6 which will therefore use gcc-4.2, and you then try to install a port Y (which depends on port X) with Xcode 4.2 which does not have gcc-4.2. You can avoid these problems by disabling the use of our pre-built binaries (set "buildfromsource always" in macports.conf) and uninstalling and reinstalling all ports after upgrading to Xcode 4.2.

Unless you have a specific need for Xcode 4.2, on Snow Leopard you may be better off using Xcode 3.2.6.


> Now onto Variants...  When I built Wine on my previous system, it
> seems as if every package used by Wine got recompiled as a +universal
> variant.  I assume this is because Wine only runs under i386 arch.

Yes, that is correct.


> I
> noticed in several places it was suggested to make +universal the
> default variant on systems running 64-bit kernels, even aside from
> Wine.  Is this actually a good procedure?

I do this on my system, but only because I want as many of our ports to build universal as possible, so I want to know about problems right away so that I can fix or report them. If you don't enjoy encountering and reporting problems, and would rather that things "just work" more of the time, and if you don't usually require 32-bit versions of your software in addition to the normal 64-bit versions, then don't put +universal into variants.conf.