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>
We have received reports of build failures due to this configuration
check modifying compile flags. Since only YJIT devs use this library
we can remove it to make Ruby easier to build for users.
See: https://github.com/rbenv/ruby-build/discussions/1933
The `CC` found by `AC_CHECK_TOOL` is prefixed by the host triplet
when cross compiling. To search for commands with `AC_CHECK_TOOL`
based on that `CC` means to search also doubly prefixed names.
As MinGW has the declaration, the `dllimport` attribute difference
is warned when compiling missing/*.c without including ruby/win32.h.
```
../src/include/ruby/missing.h:316:17: warning: 'execv' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
316 | RUBY_EXTERN int execv(const char *, char *const []);
| ^~~~~
```
Winsock's `shutdown` is incompatible with the other platforms.
And autoconf fails to detect WINAPI functions on 32bit Windows,
probably due to the argument size suffixes.
configure.ac: setup build tools and register objects
main.c: wrap main with rb_wasm_rt_start to handle asyncify unwinds
tool/m4/ruby_wasm_tools.m4: setup default command based on WASI_SDK_PATH
environment variable. checks wasm-opt which is used for asyncify.
tool/wasm-clangw wasm/wasm-opt: a clang wrapper which replaces real
wasm-opt with do-nothing wasm-opt to avoid misoptimization before
asyncify. asyncify is performed at POSTLINK, but clang linker driver
tries to run optimization by wasm-opt unconditionally. inlining pass
at wasm level breaks asyncify's assumption, so should not optimize
before POSTLIK.
wasm/GNUmakefile.in: wasm specific rules to compile objects
These flags are very wasi-libc version specific, so updating wasi-libc
may break the build. But supporting multiple wasi-libc versions in ruby
doesn't have much benefit because wasi-libc is not installed in most
systems.
The madvise() declaration should always be compiled on Solaris
to check whether the declaration is good on the environment.
For the purpose, the #if line is unnecessary.
(There was also a trivial typo that the #if was not closed
by #endif and the check always failed with preprocessor error.)
SunC
```
"cont.c", line 24: identifier redeclared: madvise
current : function(pointer to char, unsigned int, int) returning int
previous: function(pointer to void, unsigned int, int) returning int : "/usr/include/sys/mman.h", line 232
```
GCC
```
cont.c:24:12: error: conflicting types for 'madvise'
24 | extern int madvise(caddr_t, size_t, int);
| ^~~~~~~
In file included from cont.c:16:
/usr/include/sys/mman.h:232:12: note: previous declaration of 'madvise' was here
232 | extern int madvise(void *, size_t, int);
| ^~~~~~~
```
On Solaris, madvise(3C) is NOT defined for SUS (XPG4v2) or later,
but MADV_* macros are defined when __EXTENSIONS__ is defined.
This may cause compile error on Solaris 10 with GCC when
"-Werror=implicit-function-declaration" and "-D_XOPEN_SOURCE=600"
are added by configure.
John Hawthorn
Jeremy Evans
Nobuyoshi Nakada
KJ Tsanaktsidis
Jeremiah Gowdy
Jeremiah Gowdy
Takashi Kokubun
nick evans
Sergey Fedorov
Jun Aruga
Aaron Patterson
Alan Wu
S-H-GAMELINKS
Alan Wu
Yuta Saito
Peter Zhu
Naohisa Goto
Yusuke Endoh