If the baseruby is explicitly specified, fail because the option is
not accepted if it does not meet the requirements. If the option is
not specified, just display the warning and continue, in the hope that
it is not needed.
Follow up GH-15809
Add `rustc_flags` option for configure that appends to RUSTC_FLAGS
flags used when compiling with rustc for customizable build flags.
It appends to existing defaults in RUSTC_FLAGS.
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
Building ZJIT requires GNU make at the moment.
To get access to `$gnumake`, lift the `make` flavour detection up to the
environment section, before the JIT section runs.
This runs the detection, but does nothing with the result.
* Fixed version requirement in messages -- ZJIT requires >= 1.85 unlike
YJIT.
* New: Detect when rust 1.85 is available, and neither --enable-yjit nor
--enable-zjit is passed to ./configure, include both YJIT and ZJIT
in the build
When relative loading, `prefix` makes no sense actually. Use the
given (or default) path as `DESTDIR` instead.
This change affects only when the relative loading is enabled and the
destdir is not given, and does not change the final installation path,
but makes the configuration options simpler a little.
This reverts commit d3b6f835d565ec1590059773fc87589ddf8adc37.
This broke the Docker builds and presumably also 32-bit machines that
don't already have libatomic installed.
Disable the shorten-64-to-32 warning for now, because it currently
generates a lot of warnings on platforms where `sizeof(void*)` is
larger than `sizeof(long)`.
TODO: Replace `long` with `ptrdiff_t` or something in the all sources.
The default non-transformed name, `ruby` target was added for the case
of `--program-transform-name` and similars, but it was occasionally
added even when no such option is used.
Previously this was listed as a suppression, but we actually want this
permanently unsanitized. This should be faster and more reliable since
TASN won't have to match against symbolicated backtraces.
This reverts commit 32bfb61d349b49ddedb7d34d9e434063324aafcc, that
requires autoconf 2.70's improved whitespace handling. It is too
early for some platforms yet.
Fix GH-13910
This is so that e.g. building with `--enable-zjit=dev` will test with the
disassembly feature. It makes more sense, saves on build time and
reveals that
`backend::arm64::tests::sp_movements_are_single_instruction` was in
fact failing with the `disasm` feature.
```
configure.ac:2803: warning: AC_CHECK_FUNCS(\
): you should use literals
../autoconf-2.72/lib/autoconf/functions.m4:117: AC_CHECK_FUNCS is expanded from...
../autoconf-2.72/lib/m4sugar/m4sh.m4:697: AS_IF is expanded from...
```
May not be supported on some 32bit architectures.
```
/usr/lib/gcc-cross/m68k-linux-gnu/14/../../../../m68k-linux-gnu/bin/ld: ../../libruby-static.a(vm.o): in function `rbimpl_atomic_u64_set_relaxed':
/home/ubuntu/build/ruby/master/m68k-linux/../src/ruby_atomic.h:60:(.text+0x2468): undefined reference to `__atomic_store_8'
/usr/lib/gcc-cross/m68k-linux-gnu/14/../../../../m68k-linux-gnu/bin/ld: ../../libruby-static.a(vm.o): in function `rbimpl_atomic_u64_load_relaxed':
/home/ubuntu/build/ruby/master/m68k-linux/../src/ruby_atomic.h:43:(.text+0x2950):
undefined reference to `__atomic_load_8'
```
This commit allows building YJIT and ZJIT simultaneously, a "combo
build". Previously, `./configure --enable-yjit --enable-zjit` failed. At
runtime, though, only one of the two can be enabled at a time.
Add a root Cargo workspace that contains both the yjit and zjit crate.
The common Rust build integration mechanisms are factored out into
defs/jit.mk.
Combo YJIT+ZJIT dev builds are supported; if either JIT uses
`--enable-*=dev`, both of them are built in dev mode.
The combo build requires Cargo, but building one JIT at a time with only
rustc in release build remains supported.
Working towards having YJIT and ZJIT in the same build, we need to
deduplicate some glue code that would otherwise cause name collision.
Add jit.c for this and build it for YJIT and ZJIT builds. Update bindgen
to look at jit.c; some shuffling of functions in the output, but the set
of functions shouldn't have changed.
