OpenJDK reports its version slightly different than Oracle Java, and
this was causing the logic in bin/ruby-build to not detect Java 7 or
higher when OpenJDK was used.
This is to fix the error when installing new gems that have executables
which match existing binstubs in the Rubinius bin directory:
"bundle" from bundler conflicts with PREFIX/gems/bin/bundle
RubyGems is supposed to override the binstub if it detects that the
previous one was also generated by RubyGems for the gem of the same
name, but its detection mechanism gets thrown off by having a double
shebang as a result of our binstubs fixing process.
https://github.com/rubygems/rubygems/blob/v2.2.2/lib/rubygems/installer.rb#L149-L154
This avoids generating binstubs with a double shebang.
When generating SHA2 checksums with `openssl`, we want to give
preference to the newer OpenSSL that might have been installed with
Homebrew. However if there's no `brew` command the ERR trap will kick in
and display the "BUILD FAILED" notice although the build would proceed
to run.
Related: c0dc8908e1Fixes#713
Prior to this we tried to use pre-built LLVM binaries since Yosemite,
but starting with Rubinius 2.3.0 this is no longer a feature of its
build system. Instead, look for "llvm" Homebrew package and suggest
installing it if it's missing.
When requested via `-h|--help`, usage text should be displayed on stdout
and the exit status should be 0.
When usage text is shown due to invalid arguments, it should be
printed to stderr and exit status should be 1.
The current error message for missing subversion is "error: please install \`svn\` and try again", leading the user to try to find and install a package named "svn" (eg. `aptitude install svn for # debian / ubuntu). Changing it to "subversion" can help users unaware that svn is a binary installed by the subversion package, get through the error.
This fixes `rbenv install -l` displaying each version twice due to
RUBY_BUILD_DEFINITIONS path containing ruby-build's own definitions path
twice: both as an rbenv plugin and by appending its own internal path.
When installing rbx over an existing location, the `gems/bin` directory
will already be a symlink to `bin/` and an attempt to recreate this will
end up in recursion that keeps growing a binstub file until the disk is full.
If RUBY_BUILD_CACHE_PATH is set (typically "`rbenv root`/cache" if it
exists), have Rubinius `./configure` script download prebuilt LLVM
versions into that directory and re-use them if already present.
Rubinius fails to download a prebuilt LLVM on Yosemite since one is not
available yet. Instead, download the prebuilt version for the previous
OS X release.
This fixes Rubinius 2.2.7+ builds, but the older ones still fail for me
on Yosemite. This could be due to the fact that they're old releases
which are not compatible with never dependencies on the system.
Newer MRIs will pick up gcc-4.2 from PATH and use that instead of
`/usr/bin/gcc`. While this worked up till now, it will not work in
Yosemite anymore since Homebrew's apple-gcc42 is generally not
compatible with 10.10.
So when CC has not explicitly been set, set it to `clang` to avoid
searching the PATH for any other gcc versions. This fixes MRI builds on
systems where apple-gcc42 is installed.
The definitions that use `require_gcc` are not compatible with Apple's
clang-powered `gcc` and need gcc-4.2 from Homebrew. However, builds
using gcc-4.2 fail on Yosemite with a warning:
couldn't understand kern.osversion `14.0.0'
Although the warning is non-fatal, the build goes to shit from there. It
seems that setting the magical value `MACOSX_DEPLOYMENT_TARGET=10.9`
makes the build work and doesn't seem to have negative consequences.
The TMPDIR check implemented in a4556a73 incorrectly reports that
TMPDIR cannot hold executables on 4.3.11(1) on Ubuntu 14.04.1 LTS.
This is because a script containing no commands returns a non-zero
exit code. Contrast the following:
bash 3.2.53(1) on OS X 10.9.5:
$ bash -c '' && echo SUCCESS
SUCCESS
bash 4.3.11(1) on Ubuntu 14.04.1 LTS:
$ bash -c '' || echo FAIL
FAIL
This patch modifies the test script to explicitly call `exit 0` to
ensure that a successful exit code is returned if the script executes
successfully.
On Fedora, this results in a nice "Fedora 19" identifier and doesn't
show the codename "Schrödinger’s Cat" which is otherwise contained in
`/etc/fedora-release`.
On Arch, this shows "Arch Linux" where previously we had no info for it
(for some reason, `/etc/arch-release` is empty).
http://www.freedesktop.org/software/systemd/man/os-release.html
