Can't build jucer in xcode 4


#1

Hi Everyone. I downloaded the latest version of juce and installed it on my new macbook pro (10.6.7, intel core i7). Juce, juce demo, hello world, and introjucer all build. Unfortunately, the Jucer does not build. Get the following error:

Invalid value ‘4.0’ for GCC_VERSION

I am not a C++ guru by any means, so if someone could explain what this is I would be greatly appreciative. In addition to an explanation, I would be grateful for solutions/suggestions offered.

Best!
—Brian—


#2

I’ve not yet switched to Xcode 4, but that problem indicates that either you need to install the older 10.4 SDK (if that’s still possible in Xcode4?), or just use a later version of GCC and target 10.5 or later.


#3

Has anyone switched to XCode 4? I tried to open my old projects and got a zillion errors so abandoned it for another day…


#4

Thanks for the replies. I actually figured it out. You need to switch the compiler version in Xcode’s build settings:

  1. go to build settings
  2. scroll down “compiler version”
  3. adjust the C/C++ compiler version to GCC 4.2

It built fine after I did this.
—Brian—


#5

Apple said in a WWDC presentation they’d remove the gcc4 compiler from future releases of xcode4 (I think in xcode 4.2), only keeping the gcc frontend to LLVM.

So I tried to compile my project with LLVM-GCC. The main project went fine, but the unit-tests fail to link miserably… :frowning:
The weird thing is that I had the same kind of errors with my main project, that disappeared when rebuilding Juce with LLVM-GCC. Now my unit-tests use exactly the same (recompiled) version of Juce, at the same path, and the LD command line between the 2 projects are exactly the same, only the object files list changes, and here is what I get:

ld: bad codegen, pointer diff in ___tcf_1 to global weak symbol juce::LeakedObjectDetector<juce::File>::getCounter()::counter for architecture i386 collect2: ld returned 1 exit status

Googling it shows a lot of projects having this issue with xcode4. No one seems to have the answer though. Some say it’s a default symbol visibility option to change, but then why would my main project have compiled without any option change?

Is there any linker guru out there with an idea?


#6

IMHO, there’s no great advantage to upgrading to XCode 4 UNLESS you can use LLVM.

If I can use LLVM, then I can finally start to use some of the C++0x features - something I’ve been wanting to do for about a decade. I’m not asking for much, just auto variables and perhaps the occasional closure… Otherwise, XCode 4 is simply have a fancy new front-end to learn, but at the end, not so much new technology.

Of course, Apple is a compassionate company that’s very thoughtful of their developers (cough cough cough, pardon me, I seem to have something caught in my throat here - oh, it’s a lump of sarcasm!) so I imagine we’ll have a solution to this issue before 2012 becomes 2013…


#7

Why do you need LLVM for that? GCC has a C++0x option that works pretty well. Boost also has a compatibility library. I’ve been using Boost’s auto and lambdas for ages. You should be careful not to make any mistake in your code though, because error messages in meta programming are a pain in the butt. That would be the only interest of LLVM to me in that case.
Maybe using Objective-C closures, aka Blocks, would require LLVM, and I’m not even sure about that.

XCode4 is pretty CPU- and Memory- hungry too. I tends to decide to index your files in the background so heavily that you actually can’t do anything else than wait. I hate that. My goal was to adapt my code to LLVM but still edit it with that good old VIM… :slight_smile:


#8

GCC has a C++0x option that works pretty well.

I tried to do that with good ol’ XCode 3.x but I couldn’t get it to fly, I believe that the gcc that XCode is using is not recent enough and I had trouble getting XCode to fully look at the newer version I installed…

But this was some time ago and just a quick try to see if I could do it without effort.

XCode4 is pretty CPU- and Memory- hungry too. I tends to decide to index your files in the background so heavily that you actually can’t do anything else than wait.

:frowning:

I have a lot of large autogenerated C++ files which get updated pretty often, that’s going to hurt. There must be - or there will be, before I use it! - a way to turn that off…


#9

Ok, some feedback from xcode4 usage in 3 words: NOT PRODUCTION READY

UI is still buggy. It is really sluggish on my dual core, and the indexing process just takes all my resources. And of course, it can’t be disabled in xcode4 as opposed to xcode3. Having to renice a process to be able to work is not what I call a professional tool. Bugs have been filed from what I’ve seen in apple’s developer’s forums. Besides, source control support is limited to svn and git and not extensible.

I’m switching back to xcode 3.2.6 which apparently includes LLVM as well.

Speaking of LLVM, I was able to solve my linking problem and compile everything with LLVM front- and back-end. The problem seemed to be that default symbol visibility has changed and all dependencies must have the same setting than the project (see http://small-engineering.blogspot.com/2011/06/ld-bad-codegen-pointer-diff-in.html#more).

I would advise using LLVM frontend to GCC if you can, because error descriptions are much clearer indeed.
Performance wise, I didn’t benchmark my software with LLVM as a compiler backend, mostly because I was about to throw my keyboard by the window every 30 min because of xcode4, but I didn’t sense any big leap. I expect to see better improvements in future releases of xcode4 (4.2 I think), as announced at WWDC, once they include their custom replacement to libstdc++, with C++0x compatibility, and its move semantics. I can see many places where Juce would benefit from move semantics, such as, like, everywhere buffers are copied several times…

So, in a word: stay away from xcode4 for the moment.