With the release of 1.9.3-p125, clang is officially supported by MRI. RVM should not require any special flags like --with-gcc=clang to install it with the default developer toolchain (XCode 4.2/4.3).
Fixing this would alleviate a significant point of confusion, as the current behavior is quite unfriendly:
Error running ' ./configure --prefix=/Users/john/.rvm/rubies/ruby-1.9.3-p125 --enable-shared --disable-install-doc --with-libyaml --with-opt-dir=/Users/john/.rvm/usr ', please read /Users/john/.rvm/log/ruby-1.9.3-p125/configure.log
There has been an error while running configure. Halting the installation.
does clang also work with mysql2 / pg gems ? if yes then I will be happy to autodetect 1.9.3-p125 and allow clang
yeah we can't just remove due to backwards compatibility, but it can be changed depending on which is pulled. Unilateral removal is out of the question though.
@jfirebaugh Just to be clear. are you asking us to REMOVE the --with-gcc=clang flag all together, or to just remove it being added to the flags for 1.9.3-p125? because that flag is still needed for prior versions of ruby and for quite a few gems that are not clang friendly (wish they didn't have to be)
what can be done is the version being installed checked for version and if 125 or higher to remove the flag. We'll still have to be able to manually pass it, just in case we have reports of it still not working. Just because MRI now supports it does not mean that the support is solid (and this is due to Apple's changes) or that, as mentioned, gems and the like now support it.
I'm not asking to drop support for the flag. I'm asking that specifying it not be a requirement in order to successfully install 1.9.3 on OS X with the default developer toolchain (i.e. Xcode 4.2 or 4.3, no gcc-4.2). rvm install 1.9.3 with no arguments should just work. It doesn't, and hasn't at least since Lion/Xcode 4.2 was released, which has been a source of confusion for lots of people. 1, 2, 3, 4 etc, etc.
rvm install 1.9.3
I've been running with 1.9.3 compiled with clang for months and not encountered any issues (even before it was officially blessed). On the other hand, I've seen firsthand the failure of rvm install 1.9.3 with a cryptic error cause annoyance for experienced Rubyists and confusion and frustration for new ones. It's time to make it just work, and if problems are subsequently encountered (I haven't seen any), get them reported upstream.
can you just do one thing for me - please check if mysql2 and pg gems work with it - so I can customize the warning note (to avoid confusion on breaking gems with native extensions)
Sure -- building and running test suites now.
All green: https://gist.github.com/1857113
MRI 1.9.3 p125 supports clang, lets handle it, update #763
please try reinstalling 1.8.7, 1.9.3-p0, 1.9.3-p125 ... this is somehow experimental code, let me know if anything fails
1.9.3-p125 successfully installed via rvm install 1.9.3 -- yay!
I get a warning for rvm install 1.8.7 --with-gcc=clang. I didn't get a warning for rvm install 1.8.7 without --with-gcc=clang. I probably should. I don't have gcc-4.2 installed, so it must have been using clang.
rvm install 1.8.7 --with-gcc=clang
rvm install 1.8.7
improved compiler/llvm detection, better handling of --with-gcc= & CC…
…=, closes \#763
…=, closes #763
ok now it's completely rewritten, it issues warning if you are going to do forced build with clang (but allows it)
if clang is autodetected and ruby is not clang compatible (1.9.3-p125+) then it errors, so specifying clang with CC or --with-gcc=clang is needed to force the build
show which gcc was found when warning llvm, update #763
Now it's broken again.
force clang when it's needed, update #763
Let me know if it fixes it - so I can update stable with the above fix.
@plentz / @jfirebaugh did you have a chance to test it again ?
@mpapis yup, it's working on head.
$ rvm install ruby-1.9.3-p125
Fetching yaml-0.1.4.tar.gz to /Users/plentz/.rvm/archives
Extracting yaml-0.1.4.tar.gz to /Users/plentz/.rvm/src
Configuring yaml in /Users/plentz/.rvm/src/yaml-0.1.4.
Compiling yaml in /Users/plentz/.rvm/src/yaml-0.1.4.
Installing yaml to /Users/plentz/.rvm/usr
Installing Ruby from source to: /Users/plentz/.rvm/rubies/ruby-1.9.3-p125, this may take a while depending on your cpu(s)...
ruby-1.9.3-p125 - #fetching
ruby-1.9.3-p125 - #extracting ruby-1.9.3-p125 to /Users/plentz/.rvm/src/ruby-1.9.3-p125
ruby-1.9.3-p125 - #extracted to /Users/plentz/.rvm/src/ruby-1.9.3-p125
ruby-1.9.3-p125 - #configuring
ruby-1.9.3-p125 - #compiling
ruby-1.9.3-p125 - #installing
Removing old Rubygems files...
Installing rubygems-1.8.17 for ruby-1.9.3-p125 ...
Installation of rubygems completed successfully.
ruby-1.9.3-p125 - adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
ruby-1.9.3-p125 - #importing default gemsets (/Users/plentz/.rvm/gemsets/)
Install of ruby-1.9.3-p125 - #complete
$ rvm 1.9.3
$ ruby -v
ruby 1.9.3p125 (2012-02-16 revision 34643) [x86_64-darwin11.3.0]
1.9.3 looks good.
1.9.3-head gives me this error message: The provided compiler '/usr/bin/gcc' is LLVM based, it is not yet fully supported by ruby and gems, please read rvm requirements.
The provided compiler '/usr/bin/gcc' is LLVM based, it is not yet fully supported by ruby and gems, please read rvm requirements.
@jfirebaugh can you provide me a --trace gist ?
fix clang ruby-head detection, fix #763
Just in case... I have just found out after you install GCC 4.7 for Lion (you'll still need Developer Tools) RVM installs 1.9.3 with no issues (clang isn't needed).
FWIW, 1.9.3 installs perfectly on a fresh install of Xcode 4.3 without needing --with-gcc=clang. This was tested on a clean new MacBook Air with the new Command Line Tools package installed from Apple.
I can attest to that. I can not however attest that 1.9.2-p318 will. Supposedly this was the first version to support the LLVM gcc. Can anyone verify that?
to make it clear no version of ruby is fully compatible with LLVM, except 1.9.3-head (which had only few failure reports).
1.9.3-p125 most likely compiles and works but has many reported problems, use on own risk.
@mpapis @remear thanks. exactly the clarification I wanted. :)