If none of Homebrew OpenSSL versions satisfy the `needs_openssl` requirement,
array iteration will reach `index=-1` and that will raise a non-fatal error
when accessing the `versions` array. This makes sure not to go past index=0.
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.
* 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>
This resolves additional issues when tr is called in a shell that
has set LC_ALL to a specific encoding. In that case, the tr may
fail to ignore binary files, expecting that they are in some
encoding.
See https://github.com/rbenv/ruby-build/issues/2279
The `http get <url> <destfile>` utility had a bug with aria2c downloader where it couldn't properly save to destfile if it was an absolute path.
I have tried having `http get <url> -` output the downloaded file to stdout, but this conflicted with the output of `log_command` (which is also to stdout) so for now let's keep using the temporary file to resolve manual URL redirects.
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.
A very common type of build failure is that the Ruby "openssl" extension failed to compile. However, when that happens, ruby-build just prints a generic "BUILD FAILED" message. To find out what happened, the user would first have to open the ruby-build log, note the "Following extensions are not compiled" section, then figure out how to find the exact location to the "ext/openssl/mkmf.log" file for more information.
Now, when `make` fails, ruby-build will automatically forward the "Following extensions are not compiled" information to stderr.
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.
It seems like there exist platforms that have wget which does not
support the `--show-progress` option. This reverts to using wget in its
default verbose mode where a progress bar and bunch more information are
printed to stderr.
