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]
