Except for GNU make which updates makefiles automatically, repeating
configure in the same directory causes `make` to stop whenever pulled
a new commit. This is unexpected in CIs.
* YJIT: Test Rust 1.58.1 as well on Cirrus
* YJIT: Avoid using a Rust 1.60.0 feature
* YJIT: Use autoconf to detect support
* YJIT: We actually need to run it
for checking it properly
* YJIT: Try cfg!(target_feature = "lse")
* Revert "YJIT: Try cfg!(target_feature = "lse")"
This reverts commit 4e2a9ca9a9c83052c23b5e205c91bdf79e88342e.
* YJIT: Add --features stats only when it works
* Update configure.ac
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
yjit uses _Unwind_* functions from libunwind. These functions
are available in libc++abi (which requires libpthread), so
add those to LDFLAGS if enabling yjit on OpenBSD.
This add support for bmake, which should allow building with
`configure --enable-yjit` for the BSDs. Tested on FreeBSD 13 and
on macOS with `configure MAKE=bmake` on a case-sensitive file system.
It works by including a fragment into the Makefile through the configure
script, similar to common.mk. It uses the always rebuild approach to
keep build system changes minimal.
The warning against `-undefined dynamic_lookup` is just a warning yet,
and many gems seem to pay no attention to warnings. Until it fails
actually, keep it as a migration path, except for standard extension
libraries and bundled extension gems.
Add the `--with-gmp-dir` to specify the prefix directory of GMP.
The`--without-gmp` option is preserved for convenience. It can
be used to force to reject using GMP even if the `--with-gmp-dir`
option is specified.
It is no longer necessary to add it to `CFLAGS`/`CPPFLAGS` later.
Furthermore, as `CPPFLAGS` is used also with C++ compiler, the option
particular to C such as `-std=gnu99` results in an error.
I tried to debug:
http://rubyci.s3.amazonaws.com/solaris10-gcc/ruby-master/log/20220905T070005Z.fail.html.gz
but I don't have sudo privilege to install dependencies such as xz on
that machine. Thus I can't extract a prebuilt libclang binary.
Anyway, if we find out ABI is different from x86_64 / aarch64, we'd like
to have sparc CI associated to GitHub to run `make mjit-bindgen`, but we
can't. Supporting this could be too hard, so I'm leaving it for now.
As commented in include/ruby/internal/abi.h, since teeny versions of
Ruby should guarantee ABI compatibility, `RUBY_ABI_VERSION` has no role
in released versions of Ruby.
Adding `ruby` to `PREP` causes the following circular dependencies
because `PREP` is used as a prerequisite by some targets required to
build `ruby` target itself.
```
make: Circular .rbconfig.time <- ruby dependency dropped.
make: Circular builtin_binary.inc <- ruby dependency dropped.
make: Circular ext/extinit.c <- ruby dependency dropped.
make: Circular ruby <- ruby dependency dropped.
```
Adding a new Make variable like `EXTPREP` only for exts may be also
reasonable, but it would introduce another complexity into our build
system. `-bundle_loader` doesn't care that link-time and run-time
loader executables are different as long as bound symbols are provided,
so it's ok to resolve from miniruby to simplify our build.
ld64 shipped with Xcode 14 emits a warning when using `-undefined
dynamic_lookup`.
```
ld: warning: -undefined dynamic_lookup may not work with chained fixups
```
Actually, `-undefined dynamic_lookup` doesn't work when:
1. Link a *shared library* with the option
2. Link it with a program that uses the chained-fixup introduced from
macOS 12 and iOS 15
because `-undefined dynamic_lookup` uses lazy-bindings and they won't be
bound while dyld fixes-up by traversing chained-fixup info.
However, we build exts as *bundles* and they are loaded only through
`dlopen`, so it's safe to use `-undefined dynamic_lookup` in theory.
So the warning produced by ld64 is false-positive, and it results
failure of option checking in configuration. Therefore, it would be an
option to ignore the warning during our configuration.
On the other hand, `-undefined dynamic_lookup` is already deprecated on
all darwin platforms except for macOS, so it's good time to get rid of
the option. ld64 also provides `-bundle_loader <executable>` option,
which allows to resolve symbols defined in the executable symtab while
linking. It behaves almost the same with `-undefined dynamic_lookup`,
but it makes the following changes:
1. Require that unresolved symbols among input objects must be defined
in the executable.
2. Lazy symbol binding will lookup only the symtab of the bundle loader
executable. (`-undefined dynamic_lookup` lookups all symtab as flat
namespace)
This patch adds `-bundle_loader $(RUBY)` when non-EXTSTATIC
configuration by assuming ruby executable can be linked before building
exts.
See "New Features" subsection under "Linking" section for chained fixup
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes
This was broken by 67e54ce408, which
resulted in " -d" being used as the mkdir_p program. I think this
is because $ac_install_sh has been set to '' at the point it is
used.
There's probably a better way to fix this, but this should allow
the OpenBSD CI to continue to work until a better fix is in place.
macOS's AvailabilityMacros.h does not contain macros for future
versions. If a version macro is not defined, consider only earlier
versions to be targeted.
The GC compaction mechanism implements a kind of read barrier by marking
some (OS) pages as unreadable, and installing a SIGBUS/SIGSEGV handler
to detect when they're accessed and invalidate an attempt to move the
object.
Unfortunately, when a debugger is attached to the Ruby interpreter on
Mac OS, the debugger will trap the EXC_BAD_ACCES mach exception before
the runtime can transform that into a SIGBUS signal and dispatch it.
Thus, execution gets stuck; any attempt to continue from the debugger
re-executes the line that caused the exception and no forward progress
can be made.
This makes it impossible to debug either the Ruby interpreter or a C
extension whilst compaction is in use.
To fix this, we disable the EXC_BAD_ACCESS handler when installing the
SIGBUS/SIGSEGV handlers, and re-enable them once the compaction is done.
The debugger will still trap on the attempt to read the bad page, but it
will be trapping the SIGBUS signal, rather than the EXC_BAD_ACCESS mach
exception. It's possible to continue from this in the debugger, which
invokes the signal handler and allows forward progress to be made.
THREAD_MODEL is exported already, so this matches that. Exporting this
is simpler than inspecting configure_args and arch and matching that up
with a specific configure.ac.
Fix GH-5976
* add coroutines for ppc & ppc64
* fix universal coroutine to include ppc & ppc64
* add powerpc*-darwin to configure.ac
* fix thread_pthread for older systems
Note this change is only for `configure.ac`, not for Windows using
`win32/configure.bat`.
```
$ ./configure --help | grep mkmf
--enable-mkmf-verbose enable verbose in mkmf
```
Run the following command to enable the mkmf verbose mode.
```
$ ./configure --enable-mkmf-verbose
$ grep MKMF_VERBOSE config.status
S["MKMF_VERBOSE"]="1"
```
In this mkmf verbose mode, when compiling a native extension, the
`rake compile` prints the compiling commands such as
"gcc -I. <...> path/to/file" instead of "compiling path/to/file".
```
$ git clone https://github.com/deivid-rodriguez/byebug.git
$ cd byebug
$ bundle install --standalone
$ bundle exec rake compile
...
gcc -I. <...> path/to/file
...
```
This fixes a bug where Ruby on macOS running on ARM would try to look in
`/usr/local/lib` for things to link against, but the libraries in that
directory are from the x86 installation of Homebrew
[ruby-core:108424]
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
1fd9573d8b
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
Nobuyoshi Nakada
Maxime Chevalier-Boisvert
Takashi Kokubun
Jeremy Evans
Alan Wu
Kenta Murata
Yuta Saito
John Hawthorn
KJ Tsanaktsidis
Jeremiah Gowdy
Jeremiah Gowdy
nick evans
Sergey Fedorov
Jun Aruga
Aaron Patterson
Alan Wu
S-H-GAMELINKS