UsingTheRightCompiler

Tue Apr 17 15:11:19 PDT 2012

No one else seems to be having the issues you are. I personally compiler a lot of ports with clang, no problem. Doesn't that tell you something ?

Your rants below are useless. Unless you intend to actually start posting useful bug reports, build logs etc. then please take your outburst elsewhere.

Chris

On 17 Apr 2012, at 9:16pm, Jeff Singleton wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120417/4a46e58d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2966 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120417/4a46e58d/attachment.bin>