To get rid of mysterious errors such as:
```
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: libruby.3.3-static.a(/): The end of the file was unexpectedly encountered
```
and
```
ld: warning: ignoring file ../../libruby.3.3-static.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture x86_64:
"_rb_rational_num", referenced from:
```
Checking by `__STDC_VERSION__` is unreliable because old gcc 4.8
supports `-std=gnu11` option but does not implement `_Thread_local`.
Check the implementation directly instead.
This is useful for passing directory file descriptors over UNIX
sockets or to child processes to avoid TOCTOU vulnerabilities.
The implementation follows the Dir.chdir code.
This will raise NotImplementedError on platforms not supporting
both fchdir and dirfd.
Implements [Feature #19347]
[Misc #16671]
I'd like to bump it to 2.7 to use pattern matching in
tool/mk_builtin_loader.rb.
However, I experienced a few blockers. 2.5 seems like the closest
version that is easy enough to use on CIs, so let me bump the version to
it as an intermediate step for it. I want to use &. and <<~ in 2.3 too.
Known blockers:
* AppVeyor Visual Studio 2015 doesn't have Ruby 2.7. You'd need to bump
the version to Visual Studio 2019.
* GitHub Actions windows-2019 doesn't have Ruby 2.7 either. You
can use ruby/setup-ruby, but configure doesn't seem to work with it.
* For ruby/ruby-ci-imaage, bionic doesn't have Ruby 2.7. I tried using
ruby-build to build Ruby 2.7 from package, but the build on its CI
seems to somehow loop forever when I do that. So I gave it up for now.
We might want to wait until bionic becomes EOL.
Note:
* AppVeyor Visual Studio 2015 has Ruby <= 2.6.3
https://www.appveyor.com/docs/windows-images-software/#ruby
* GitHub Actions windows-2019 uses Ruby 2.5.9
https://github.com/actions/runner-images/blob/main/images/win/Windows2019-Readme.md
libcapstone used to break when it's linked from C and Rust at the same
time, but it doesn't seem to happen anymore. Maybe it's related to
recent symbol hygiene changes. Thank you if that's the case.
This commit allows you to make both --enable-rjit=dev and
--enable-yjit=dev work in the same binary.
We used to require MJIT is supported when YJIT is supported. However,
now that RJIT dropped some platforms that YJIT supports, it no longer
makes sense. We should be able to enable only YJIT, and vice versa.
On macOS, it is not used to localize symbols in dynamic libraries
(libruby.dylib and libyjit.o). Instead, using `objcopy` which does
not support recent mach-O causes linker errors as bellow.
```
linking shared-library libruby.3.3.dylib
error: cannot parse the debug map for 'libruby.3.3.dylib': Invalid data was encountered while parsing the file
linking ruby
ld: malformed mach-o: LC_*_DYLIB load command string extends beyond end of load command file './libruby.3.3.dylib'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
YJIT will need it to address symbol leakage issue. Fallback to `:` when
OBJCOPY is not available on the system.
Co-authored-by: Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
This was a difference from using a GNU toolchain previously. It wasn't a
problem because we don't invoke $(LD) in the Makefile currently. YJIT
will want to invoke LD, so needs this consistency.
This repairs the assumption, which many fat-gem maintainer expect, "An
extension built with --disable-shared Ruby is loadable from
--enable-shared Ruby".
By default all references resolved to a dynamic library use "two-level
namespace", which record the library name and symbol name for each
resolution entry. On the other hand, `-flat_namespace` discards the
library name information and resolves symbols "flatly".
This behavior is useful for us to ignore which image (`ruby`
executable or `libruby.dylib`) provides rb symbols at runtime.
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
Takashi Kokubun
Nobuyoshi Nakada
Jeremy Evans
小MAO钓鱼
Alan Wu
NARUSE, Yui
Yuta Saito
Mike Dalessio
Maxime Chevalier-Boisvert
Samuel Williams