This happens while compiling OpenSSL or any other non-Ruby package:
ruby-build: line 723: [: : integer expression expected
This was because $ruby_semver was checked as a numeric value but was never set.
System openssl version reported by `pkg-config --modversion openssl` might end
with a letter, e.g. "1.0.2k", due to OpenSSL versioning policy prior to OpenSSL v3:
https://www.openssl-library.org/policies/general/versioning-policy/#history
The letter would trip up the normalize_semver function due to it only handling numbers.
This change switches to semver parsing via awk instead of doing it clumsily in
bash. This also changes the multiplication factor of major version numbers,
from 100000 to 10000, and adjusts static version comparisons accodingly.
Skip downloading and building OpenSSL if a compatible version was found with pkg-config, but only if that openssl version isn't under Homebrew's "cellar".
---------
Co-authored-by: Mislav Marohnić <git@mislav.net>
The recent rpath argument addition broke compilation of OpenSSL with clang since
it seems expect this syntax (comma instead of "="):
-Wl,-rpath,<path>
Also, it doesn't seem that the rpath argument is necessary for any platform other
than "Linux"; that is, we should skip passing it on BSD and macOS.
* Fix library lookup path in the vendored OpenSSL
When a vendored OpenSSL is needed for compiling Ruby, that OpenSSL installation
ends up with its `bin/openssl` executable broken due to not finding "libssl.so"
and "libcrypto.so" in the global load path for libraries. This doesn't seem to
negatively affect the Ruby "openssl" extension, but is a broken OpenSSL install
nevertheless.
This change causes the `bin/openssl` executable and related shared libraries to
be built with an "RPATH" pointing to the "lib" directory of the vendored OpenSSL.
* fix test
On 64-bit systems, the build system for OpenSSL tends to produce a "lib64"
directory instead of a "lib" directory due to its "multilib" feature being
enabled by default. However, the Ruby "openssl" extension assumes that the
directory is always named "lib", or explicitly passed via `--with-openssl-lib`.
This disables multilib support in OpenSSL by passing `--libdir=lib` to OpenSSL
configure step.
* Only from Ruby 2.4+ since older releases don't use --enable-shared by default.
* As with releases it can be disabled by setting RUBY_CONFIGURE_OPTS=--disable-shared.
* By searching a X.Y.Z definition if no ruby-X.Y.Z definition is not found.
* Add test and documentation.
Co-authored-by: Mislav Marohnić <git@mislav.net>
Explicitly set PKG_CONFIG_PATH when `--with-openssl-dir` is used for older Rubies.
Otherwise, Ruby will attempt to link to the latest OpenSSL found by pkg-config,
which could be incompatible.
This merges "standard_build" and "standard_install" build steps into one again
and modifies "standard_install_with_bundled_gems" to just invoke "standard"
with the addition of `update-gems` & `extract-gems` targets.
Using `--with-ext=+` only has the indended effect (compiling all extensions that would normally get compiled) on Ruby 2.5+. On older versions, it causes none of the default extensions to get compiled, resulting in a defunct installation.
Normally, Ruby `make` step will print a warning about any missing
extensions, but will not abort the build and instead proceed as normal.
Since Ruby installations without openssl or psych are essentially
broken, ruby-build used to have a `verify_openssl` build step to test if
the newly built Ruby can load these extensions, and print helpful
information and abort the build on errors:
Loading the Ruby openssl extension failed
ERROR: Ruby install aborted due to missing extensions
The `verify_opensl` implementation was necessary to provide a good
experience for ruby-build users, but was hacky and I would prefer to
eliminate it.
It appears that passing `--with-ext=openssl,psych` to the Ruby configure
step marks those extensions as mandatory and fails the `make` process if
they failed to build. This is exactly the behavior we want, so this
enables the configure option for all Ruby builds.
This removes the `isolated_gem_dependency` hack as well as the `rake` &
`bundle` shell wrapper functions. The main reason is to avoid having to
use the `command` shell builtin to be able to invoke the real `rake` and
`bundle`. In my testing on bash 3.2, `command` does not respect the
usual bash error handling rules, and thus a failed `command` invocation
can trigger the ERR trap mechanism even when we don't want it to.
If a system OpenSSL version was not found or is at version that is incompatible with a Ruby being installed, ruby-build would typically download and compile a new OpenSSL version scoped to that Ruby installation.
Now the `needs_openssl` condition will also check for Homebrew-installed OpenSSL and automatically link to the first one found that satisfies the version requirement. This primarily helps speed up Ruby installation on macOS where the system OpenSSL is never compatible and where Homebrew is a de-facto standard package manager.
- Now only generates a `configure` script if explicitly specified
- Add ability to add arbitrary files to the tarball
- Cache most common tarballs in fixtures directory to speed up tests
The default settings for LDFLAGS and CPPFLAGS were there since the initial commit to ruby-build:
LDFLAGS="-L${PREFIX_PATH}/lib"
CPPFLAGS="-I${PREFIX_PATH}/include"
However, it's not clear to me what these settings help with. A typical Ruby installation will initialize files in these directories, but it will do so regardless of the environment variables.
So, let's remove them and see what breaks.
This was set to gmake in https://github.com/rbenv/ruby-build/pull/1381
as a workaround for https://bugs.ruby-lang.org/issues/16331
YJIT builds in Ruby 3.3 previews require the use of BSD make on these
platforms, and no supported version of MRI requires the use of gmake, so
revert this.
JRuby continues to require gmake for jruby-launcher.
Fixes#2262
Co-authored-by: Mislav Marohnić <git@mislav.net>
MRI's BigInt use GMP under the hood if available, and if not
fallbacks to an homemade implementation with much worse performance.
Without GMP:
```
>> Benchmark.realtime { Integer('1' * (10 ** 7)) }
=> 13.80743500002427
```
With GMP
```
>> Benchmark.realtime { Integer('1' * (10 ** 7)) }
=> 0.4098639999865554
```
macOS not being a common production platform, it's not a huge deal
but it would still preferable to compile with `gmp.h` if present.
I'd also suggest to print a warning if compiling on macOS and gmp
isn't installed, but I don't know if it's desirable.
NB: `--with-gmp-dir` was only added recently, so this will only
apply to MRI >= 3.2, as well as rubies on which this flag was backported.
* Fixes https://github.com/rbenv/ruby-build/issues/1798
* OpenJDK 17 reports:
$ java -version
openjdk version "17" 2021-09-14
There is no dot in the version, so we need to only use the first match from grep -o.
* Clarify it is a minimum required java version, not an exact version.
