UsingTheRightCompiler

[Jeremy Lavergne]

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

Continuing to chant "it doesn't work" is just as helpful. Post logs detailing your issues and point them out. You've been asked to do this a couple times now.

Without those, the whole thread appears useless.

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

Do you use -Wall when you compile with GCC?

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

Why not actually explore the issue with us? Logs needed.

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

One possible way that can happen is you're pulling down prebuilt binaries built differently than you're attempting: python, perl and a few others record their compilers and flags, and subsequent python/perl packages pick up on those. At this point I'd assume you've already disabled them since they're part of the standard output of MacPorts (verbose/debug flags not needed to see these being installed), but do you have these disabled?

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

If editing the Portfile resolves the issue then it appears to be a problem with the Portfile. Care to post any specific changes so we can look into it?

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

You have unhindered access to the source code--that's open.

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

And you have the ability to actually help the developers find any bugs you uncover. Do so.

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