use a different default configure.compiler (was: UsingTheRightCompiler)

[Ryan Schmidt]

On Apr 15, 2012, at 23:04, Jeff Singleton wrote:

> I just can't say a lot for Clang.  I have mentioned this before.  I have taken many suggestions.  Tried Tried and Tried some more to like Clang.
> 
> I just can't do it.
> 
> Its ugly.  It causes more problems between ports that depend on one another, yet some are built with Clang, other built with GCC.

I've not heard of any problems related to some ports being built with clang and others built with other compilers; if you have examples of this please let us know.


> I am simply fed up with Clang and I don't really want to use it anymore. Clang does't respect architecture settings, no matter which I use (i386 or x86_64).

clang of course does respect -arch settings. If individual ports that are compiling with an Xcode compiler (gcc-4.2, llvm-gcc-4.2 or clang) do not respect -arch settings, please file bug reports against those ports. (MacPorts gcc compilers do not respect -arch flags, so ports that use them cannot be made to respect -arch flags either.)


> Case and point - Pango crashes during compile no matter which Arch I use:
> 
> libtool: link: /usr/bin/clang  -o .libs/pango-basic-coretext.so -bundle  .libs/basic-coretext.o   -framework Carbon -L/opt/local/lib  -O2 -arch x86_64 -arch x86_64   -framework Carbon -Wl,-exported_symbols_list,.libs/pango-basic-coretext-symbols.expsym
> Undefined symbols for architecture x86_64:
> <snip unnecessary error output>
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> I am just sick of running into linking errors -- either they happen now, or they happen eventually during an upgrade.  Either way, I usually end up getting frustrated, and wiping out my whole ports tree, and attempt to rebuild from scratch.
> 
> In this case…I still hit that link error with Pango.

The "unnecessary error output" you snipped above might have been just what we needed to know whether this is a problem we've seen before or not. I have a feeling this is #32722 — which is not clang-specific, by the way; I see it on my Snow Leopard machine too, using gcc-4.2. The problem here is the quartz and/or no_x11 variants. I have enlisted the help of the pango developers in understanding why this is happening and how to fix it.


> Would someone PLEASE just tell me how I can force the default compiler to be GCC. No configure.compiler does not work, and no environment variables CC CPP CXX do not work.  I have both set to gcc-4.2 and yet Pango still defaults to use Clang and crashes no matter what I try.
> 
> I don't want to edit every single Portfile when I hit this issue, because when I sync again, my changes go away.
> 
> There simply HAS to be some way of forcing Macports to use the compiler that I want to use and not argue and not make changes whenever and just do what I tell it to.
> 
> Is that so much to ask?  Can I please just use GCC and never EVER have to see another Clang linking error again. PLEASE!???!

As of MacPorts 2.1.0 beta 1 yes you can override the default value of configure.compiler than MacPorts chose for you, so feel free to upgrade to that version and change the appropriate value in macports.conf. Note that individual ports might specify an alternate compiler, if it is already known that using a particular compiler will not work (but I can't think of many ports that wouldn't work with Apple gcc 4.2). Note that Xcode 4.2 and up no longer include any Apple gcc compilers, so you cannot set configure.compiler to gcc-4.2 if you have Xcode 4.2 or later. You can however install the apple-gcc42 port, which is basically the same thing, and set configure.compiler to apple-gcc-4.2.