This only occurs with Xcode 4.2, while 4.1 has no issue. Reason is Apple went LLVM.
I encountered the issue previously with rbenv [0]. Even if it builds correctly with clang various tests subsequenty fail, although they appear to pass on ruby trunk.
So for now, one should rather install gcc via the installer, which also allows to build older versions of ruby if need be.
Please reread, including comments in the linked github post. 1.9.3 does compile with clang, but ruby's own test suite ('make test' in the ruby build dir) does not pass.
Also, if you had 4.1 then upgraded to 4.2 you may still have 4.1 gcc around.
I just recently started learning Rails (purely out of interest).
Getting any form of Rails installed was a massive pain in the neck. Between GCC issues and architecture issues involving sqlite3 (for some reason), it must have taken over 12 hours of tinkering before I could even start the rails guide.
Nearly gave up on Ruby/Rails many times out of frustration. Glad I stuck it out though.
It's this kind of thing that makes it extremely difficult to learn programming in your spare time. Getting the dev environment set up for someone who isn't well-versed in the process is almost frustrating enough to make you quit before you even write a line of code. I think that's why I'm enjoying and sticking with the CodeYear project where other efforts have fizzled out.
I was really hoping this was someone talking about making Ruby 1.9.3 compile with llvm-gcc. At home, I'm running ruby compiled with clang and I've noticed the occasional hiccup with some gems. But, unlike the author, I do use software installed with XCode (iOS dev kit) so uninstalling XCode isn't really an option.
For what it's worth, there are a ton of recommendations to do this same thing out there--and for many people it's just not a viable option. This isn't a success story so much as it's using a workaround. Not being part of either the Ruby or Apple dev teams, I won't say whose side this is on to fix: only that it needs to be fixed.
The "success story" works just as fine without uninstalling Xcode: that's just "the bonus" - you can uninstall it if you don't use it for anything else.
Am I the only person that thinks RVM is a symptom of a serious problem? It should not be this hard to manage a software environment.
And by "hard" I don't mean "hard for end-users", although it's quite a lot of hoops to jump through for someone who just wants to get up to speed with the current state of the art. I mean the amount of work that has gone into things like RVM and Bundler and other tools to make developing serious software in Ruby possible.
It's clearly possible to develop serious software without tools like rvm and bundler, the whole world has been doing it for quite awhile before they came about. We did things like putting library dependencies into source control and beating our heads against versioning problems. So I would view them only as steps to a better programming environment.
In fact, I'm not sure a much better approach exists for an environment like ruby. .NET issues patches all the time that magically show up and hopefully don't break things. You don't get side-by-side patch releases. The JVM does have patch releases, and it comes with environment problems similar to ruby. They're often transferred to dev tool users in the form of the JAVA_HOME environment variable.
It seems like the core issues that separate ruby from java come from the existence of rubygems and the fact that it likes to install things globally. So in this way, bundler could be a better solution to the problem that rvm/rbenv solve.
One issue I always have is the various path env variables (GEM_HOME, etc) that you have to set on a per-directory basis on hosting environments. Right now, I have an alias command in my .zshrc that sets the path based on the current directory, but something tells me there is a better way to handle it.
