UsingTheRightCompiler

[Jeremy Huddleston]

On Apr 15, 2012, at 9:04 PM, Jeff Singleton <gvibe06 at gmail.com> 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.

clang is awesome.  What problems do you have?  Give specifics.  Your entire rambling email does not actually describe a single issue with clang, nor UsingTheRightCompiler (which is about getting ports to respect ${configure.compiler}, not about you setting what you want for configure.compiler.

> Its ugly.  It causes more problems between ports that depend on one
> another, yet some are built with Clang, other built with GCC.

There are no problems here.  Binaries built with clang are compatible with those built by other compilers.  What specific issues are you seeing?

> 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).

Yes it does.  It respects them better than gcc (which doesn't btw, it's Apple's driver-driver that parses those).

> Case and point - Pango crashes during compile no matter which Arch I use:

That's not a crash.

> *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)*


Yous snipped out necessary output.  This is not a clang issue.  It's a linking issue.  The problem has *NOTHING* to do with clang.  You probably have an i386 library installed that you're trying to link into an x86_64 binary.

> 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.

Ok, that's one way to deal with it, but this has nothing to do with clang, and you should report individual linking issues separately.  There's probably a missing dependency somewhere, or something was built +universal but it actually is thinned to i386 because the *port* doesn't support +universal (again, nothing to do with clang).

> In this case…I still hit that link error with Pango.

Please file a bug with the full output (including the relevant sections that you commented out as unnecessary)

> Would someone PLEASE just tell me how I can force the default compiler to
> be GCC.

Use trunk base, but there's no way I'm going to support you using anything other than clang on modern systems.

> No configure.compiler does not work

yes it does.

> , and no environment variables
> CC CPP CXX do not work.  

No, they don't

> I have both set to gcc-4.2 and yet Pango still
> defaults to use Clang and crashes no matter what I try.

It doesn't crash.  Also the fact that it fails despite you setting it to gcc-4.2 should prove to you that it has NOTHING to do with clang.

> I don't want to edit every single Portfile when I hit this issue, because
> when I sync again, my changes go away.

That would be stupid.

> 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.

There is.

> Is that so much to ask?  Can I please just use GCC and never EVER have to
> see another Clang linking error again.

clang doesn't have linking errors.  clang doesn't link.  ld64 links, and guess what, gcc-4.2 uses the same linker as clang.

--Jeremy