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 <jerem...@macports.org> > wrote: > > On Apr 15, 2012, at 9:04 PM, Jeff Singleton <gvib...@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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users