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.
Example:
install_package openssl-1.1 "https://..." --if needs_openssl:1.0.1-3.1.x
In the example, the two values are passed as arguments to the `needs_openssl` function.
LC_CTYPE is "utf-8" on macOS, which instructs utilities like `tr` to expect Unicode input. However, in case of binary files, which we here explicitly guard against, the utility will fail because of invalid input encoding.
The solution is to set LC_CTYPE=C which effectively removes the expectation around input encoding and allows `tr` to process the input byte-by-byte.
TruffleRuby build definitions used to explicitly rely on `brew --prefix openssl@1.1` on macOS and abort installation if that was not found. However, this check didn't take into account that the user might have set OPENSSL_PREFIX in their environment, or that they have another `openssl@*` version installed via Homebrew. This change removes the `use_homebrew_openssl` check and allows TruffleRuby to perform its own OpenSSL detection.
https://github.com/oracle/truffleruby/blob/vm-23.1.0/lib/truffle/truffle/openssl-prefix.rb#L14-L17
Reuse original `build_package_copy` instead of having to maintain an additional `build_package_copy_to` step.
As a bonus, this prevents a global variable `to` from leaking.
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.
- The `make -j 1` workaround seems neither in effect nor necessary anymore
- Assume that KERNEL_BITS workaround isn't necessary anymore
- Declare more variables as local
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>
I was encountering some build issues on MicroOS and needed the actual exception message in order to pinpoint a workaround.
Co-authored-by: Mislav Marohnić <git@mislav.net>
This was only used in Ruby versions < 1.9.3, which are now EOL.
This also removes a 11-years old workaround for building Ruby 2.0 with clang.
06d7994bcf
This was used by Rubinius over the years to ensure that a correct llvm version was selected from the ones available on the system, but for recent Rubinius this function is a no-op, and since Rubinius isn't an actively maintained project anymore, I don't feel strongly for keeping ruby-build workarounds that only help ancient Rubinius versions.
* Use pkg info for readline/libedit prefix on FreeBSD instead of hardcoding it
* Use yaml and ffi installed via pkg on FreeBSD
* Remove check for FreeBSD version and allow all versions
