Compiler variants in portfile

Sean Farley sean at
Fri Apr 18 11:39:14 PDT 2014

Sébastien Maret <sebastien.maret at> writes:


>>>>>>>> You do know that as of Mavericks, trying to compile C++ code with anything other than clang is a fool’s errand, right?
>>>>>>> No, I didn’t know that.
>>>>>>>> *Why* is it not possible to compile your software using CC=clang and FC=gfortran-mp-4.8?
>>>>>>> I tried that but the compilation failed. I don’t exactly why but I’ll have a closer look. 
>>>>>> Sorry for the late reply, but it took me a while to catch up. Ryan is
>>>>>> right, of course. You should really figure out why they aren't compiling
>>>>>> and try to fix those errors.
>>>>> Thanks for your answer.
>>>>> I found the problem: the link was done against libstdc++ instead if libc++. I’ve fixed this and I’ve just posted a revised version of the port on the tracker.

The real issue is that gildas has no sane configuration system. The
makefile tries to define the link line and requires the user to figure
out which c++ library to link to via 'ar' for static libraries. Usually,
libtool or the c++ compiler is used for linking.

>>>> Looking at the portfile, things seem mostly fine. A few comments (which
>>>> will hopefully help start documenting the compilers portgroup :-)
>>>> - compilers.choose is really meant to serve as a way to isolate a c-only
>>>> or fortran-only build; since you specify both, you don't need it
>>> But isn’t this needed to set both CC, FC and CPP ? 
>> No, if you leave compilers.choose blank, then it will set all the compilers.
>>>> - removing the clang variants only stops macport's clang compilers from
>>>> being used; this is fine but since you don't need c++ you could mix
>>>> clang with gfortran
>>> Indeed I do need C++. And since a Fortran compiler is also needed, I would prefer to compiling Fortran and C with compilers from the same compiler suite (GCC) to avoid link problems. In addition the package requires CPP from GCC to compile properly (it is used in a non-standard way to pre-process Fortran code, and this does not work with Apple’s CPP).
>> If you need C++, then you forgot to mention it in compilers.choose
>> (missing 'cxx’).
> If i put cxx in compilers.choose (or leave compilers.choose blank) and install the +gcc48 variant the package, it uses g++-mp-4.8 to compile the C++ part of the code. This is not what I want. I need the C++ code to be compiled with clang++ (as advised by Ryan), and the rest with GCC4.8. Setting compilers.choose to  "cc cpp fc » does this.

Ok, I see the confusion now. Ryan was pointing out that Mavericks only
ships with libc++ and that you can't mix libstdc++ with libc++ since
they aren't ABI compatible. This means care must be taken when doing the
linking, especially on systems pre-Mavericks.

> By the way: this compiling C++ with anything other than clang is not recommended, shouldn’t compilers 1.0 enforce that rule and set compiler.cxx to clang++ by default?

Well, you can compile with g++ (I was able to get it to work), it's just
that you have to make sure to link to the correct library and not mix
libc++ with libstdc++. The upcoming MacPorts release will have a
configure.cxx_stdlib variable that should help.

>> Also, "non-standard way to pre-process Fortran code"
>> ... I didn't realize Fortran had a standard ;-P
>>> In fact I removed the clang variants because clang does not compile Fortran (same for drgaonegg). Why are variants present when require_fortran is set ? 
>> But dragonegg does compiler Fortran? That's mostly why it existed.
> I didn’t know that. Yet clang does not compile Fortran, and it shows up in the variants even when require_fortran is set. But I guess it is the port file developer responsibility to blacklist compiler than can’t compile his port.

Yes, clang is a C interface to LLVM. Dragonegg used gcc's parsers to
feed LLVM so that fortran (and other) languages could use LLVM. My
design of the compilers portgroup was to help providing a fortran
compiler in cases like clang. There is a lack of documentation, for

More information about the macports-dev mailing list