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.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
