Tested on production workloads at Shopify for > 1 year and proven
to be quite stable. Enabling YJIT at run-time is still guarded
behind the --yjit command-line option for now.
It's unspecified by POSIX. zsh and dash give a newline and
bash doesn't substitute it. Attributes don't have to be
followed by a newline anyway, so just remove it.
[Bug #19174]
For people using Rosetta 2 on ARM Macs, it can happen that the
rustc in the PATH compiles for x86_64 while clang is targeting
ARM. We were enabling YJIT in these situations because the test
program compiled fine, but caused linking failure later due to
the architecture mismatch.
Adjust the test program to fail when rustc's target arch is different
from ruby's target arch.
[Bug #19146]
* Windows: Fix warning about undefined if_indextoname()
* Windows: Fix UNIXSocket on MINGW and make .pair more reliable
* Windows: Use nonblock=true for read tests with scheduler
* Windows: Move socket detection from File.socket? to File.stat
Add S_IFSOCK to Windows and interpret reparse points accordingly.
Enable tests that work now.
* Windows: Use wide-char functions to UNIXSocket
This fixes behaviour with non-ASCII characters.
It also fixes deletion of temporary UNIXSocket.pair files.
* Windows: Add UNIXSocket tests for specifics of Windows impl.
* Windows: fix VC build due to missing _snwprintf
Avoid usage of _snwprintf, since it fails linking ruby.dll like so:
linking shared-library x64-vcruntime140-ruby320.dll
x64-vcruntime140-ruby320.def : error LNK2001: unresolved external symbol snwprintf
x64-vcruntime140-ruby320.def : error LNK2001: unresolved external symbol vsnwprintf_l
whereas linking miniruby.exe succeeds.
This patch uses snprintf on the UTF-8 string instead.
Also remove branch GetWindowsDirectoryW, since it doesn't work.
* Windows: Fix dangling symlink test failures
Co-authored-by: Lars Kanis <kanis@comcard.de>
The bundle_loader check for darwin checks EXTSTATIC, but previously the
setup for the variable comes after the check. I had trouble building
using --with-static-linked-ext on darwin before this change.
Preivously we didn't have a "checking ...." line for this check and when
rustc was too old, we would dump the error message to the console like:
checking for rustc... rustc
error: there is no argument named `x`
--> <anon>:1:33
|
1 | fn main() { let x = 1; format!("{x}"); }
| ^^^
error: aborting due to previous error
`configure` checks usually don't do this and this might be confusing.
With this commit it now says something like:
checking whether rustc is new enough for YJIT... no
* Auto-enable YJIT build when rustc >= 1.58.0 present
* Try different incantation to have rustc output to stdout only
* Add comment, remove whitespace
* Try to detect if we are on a platform on which YJIT is supported
Previously, enabling only "disasm" didn't actually build. Since these
two features are closely related and we don't really use one without the
other, let's simplify and merge the two features together.
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
