MacPorts and OpenMP---or how to build "everything" with MacPorts GCC?

[Ryan Schmidt]

On Jun 20, 2013, at 07:41, Hans Ekkehard Plesser wrote:

> I am one of the developers of NEST, the Neural Simulation Tool (www.nest-initiative.org). Our users work on everything from extremely large computers to laptops running Linux or OSX. In the past, supporting NEST on OSX was reasonably easy using MacPorts, but over the past year two developments have been working against us: 
> 
> - We have started to use OpenMP in NEST.
> - Apple has made Clang the standard compiler, and Clang does not support OpenMP.
> 
> While NEST can be built without OpenMP, it loses performance, so we really would like to build NEST with OpenMP. We can do that with either llvm-gcc42 or with the one of the MacPorts GCCs, but this leads to a number of problems:
> 
> - NEST has a Python UI. Building NEST with a different compiler than Python usually leads to trouble.
> - NEST can also be compiled with OpenMPI. For this to work well, NEST should be built with the same compiler as OpenMPI.
> - NEST links against GSL. Here we have experience little trouble, but ideally we should use the same compiler for GSL and NEST, too.
> 
> Everything would be solved if I could download MacPorts, configure it to use, e.g., MacPorts gcc 4.7 to build everything, and then install all the ports I need for NEST---I could even write a Portfile for NEST :). But as things stand, Python and OpenMPI are compiled with Clang, and as far as I can see there aren't even variants that allow you to switch the compiler to GCC (the +gccNN variants of OpenMPI only select the Fortran compiler).

You can configure MacPorts to do that. There is a setting in macports.conf you can set too override its usual default compiler choice. (Individual ports might still override that, for reasons specific to those ports.) I forget what the option is called and it is not documented or advertised because we don't really want users to do that, because use of a nonstandard compiler has not been tested by anyone and you'll probably run into a fair share of ports that won't compile. However, if you do, that's probably a bug in the port that should be fixed (at a minimum by having the port declare itself to be incompatible with that compiler (using compiler.blacklist) and use a fallback compiler).

If you change the default compiler, you will also want to instruct MacPorts to never download a binary from our server (by setting "buildfromsource always" in macports.conf), otherwise you could get a binary built with a different compiler than the one you want.


> I much appreciate MacPorts philosophy of making itself maximally independent from tools shipped with OSX. Therefore, I have never quite understood why MacPorts insists on using the system compiler. I very well understand that it is virtually impossible to support a range of compilers, but why not use MacPorts own GCC as default then? As most of the packages provided through MacPorts originate from the Unix/Linux-world, I'd expect them to be GCC-friendly.
> 
> I'd much appreciate some information on why MacPorts has made the choices it has made and whether there are any plans for change.

FSF GCC did not used to support -arch flags, which MacPorts uses to give the user the choice of architecture(s) to compile for. My understanding is that gcc47 finally supports -arch flags so this is no longer a problem.

MacPorts previous compiled all ports locally on the user's system. Compiling gcc takes a long time. Requiring users to compile a compiler was therefore expensive, and would besides require a compiler already be installed (i.e. by installing Xcode). Now we have a buildbot that compiles binaries that can be distributed to users so this is not so much of a problem anymore, however not all users are able to use our binaries. There are a dozen or more factors that can cause them to be unavailable to a user.

We are trying to follow Apple's lead on compiler choice. Most developers who test on the Mac will test with the default compiler Apple uses. MacPorts therefore defaults to whatever compiler Apple chose as default on the currently-installed version of Xcode. Defaulting to gcc47 could introduce new unexpected problems that developers have never seen before.

gcc43 and later are under version 3 of the GPL. Apple seems to have made a corporate decision to not use or look at the source code of any software under that license. Therefore if we ran into any compiler problems Apple would not help us. On the other hand, Apple develops clang and is interested in fixing its bugs.

clang is a nice compiler that has benefits over gcc, including more-informative error messages.