UsingTheRightCompiler

[Jeff Singleton]

Nope. Sorry.  But the "it works for me" argument just isn't going to work.

I have tried both i386 (32 bit) and x86_64…and have the same issues
(eventually) and IT IS because of Clang. I have never had so many problems
compiling with GCC, and then maintaining them through normal upgrades. I
use Macports for the convenience, and because its supported…but having to
rebuild from scratch over and over is becoming not-so-convenient.

If its not Clang as you suggest, and you think its a linking issue, then it
is a Macports problem.  I don't mix my architectures. My macports.conf
either says build_arch i386 or it says build_arch x86_64.  I don't add
anything to the command line other than the occasional variant.

So how do x86_64 binaries/libraries get into an i386 Prefix and vice versa?
Whenever I switch in an effort to troubleshoot a compile issue like this, I
*ALWAYS* clean/delete the entire folder, and reinstall Macports before
commencing.  So if there is mixed arch linking going on, then Macports is
the problem.

configure.compiler does not work on the command line as stated before.  I
have tried it several times, and Clang seems to be preferred and chosen
every time despite it. I end up having to edit Portfiles to force the
compiler I want to use, and that gets to be to much work to maintain.

All I am asking for is to be able to choose my preferred compiler and not
be forced to use whatever Macport devs prefer.  I mean, its not really open
if I have to use the compiler you tell me to, is it?

If Macports was a sponsored, non-free package management distribution, I
would understand having to use the developer chosen compiler. But its not,
so therefore we should have more flexibility in choosing things like what
compiler to use.

Jeff

On Mon, Apr 16, 2012 at 8:35 PM, Jeremy Huddleston <jeremyhu at macports.org>wrote:

>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120417/078a7c18/attachment.html>