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>
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.
This allows easy differentiation between ABI incompatible platforms like MSWIN64 and MSVCRT-based MINGW32.
This also implicates a distinct rubygem platform which is also "x64-mingw-ucrt".
Although the term "mingw32" is the OS-part for 64 bit systems as well, the "32" is misleading and confusing for many users.
Therefore the new platform string drops the "32" from the OS part to just "mingw".
This conforms to the common practice of windows platform testing per RUBY_PLATFORM=~/mswin|mingw/ .
Find jemalloc header first, then using the found header, try [with
mangle, without mangle] x [no more additional libraries, adding
jemalloc] combination.
It is reported that combination of `--enable-shared --with-jemalloc`
breaks on Debian bullseye (testig). Deeper investigation revealed that
this system's `ld(1)` is patched, to turn `ld --as-needed` on by
default.
This linker flag strips "unnecessary" library dependencies from an
executable. In case of `ruby(1)` (of `--enable-shared`), because
everything is in `libruby.so`, the binary itself doesn't include any
calls to `malloc(3)` at all. So in spite of our explicit `-ljemalloc`
flag, it is ignored. Libc's one is chosen instead.
This is not what we want. Let's force our `ruby(1)` link what we want.
Fixes https://github.com/ruby/ruby/pull/4627
The author would like to acknowledge
Akihiko Odaki <akihiko.odaki@gmail.com> for their contributions.
On darwin we avoid including sys/user.h to avoid a conflict. Previously
we still ended up with PAGE_SIZE being defined because the headers for
system malloc define it. However, when compiling with jemalloc nothing
would define PAGE_SIZE.
This commit changes configure.ac so that we never use the PAGE_SIZE
constant on darwin and to always use the sysconf fallback.
The current fix for PAGE_SIZE macro detection in autoconf does not work
correctly. I see the following output with running configure on Linux:
```
checking PAGE_SIZE is defined... no
```
Linux has PAGE_SIZE macro. This is happening because the macro exists in
sys/user.h and not in the malloc headers.
include/ruby/internal/has/builtin.h uses HAVE_BUILTIN___BUILTIN_EXPECT
for icc but previously it was not defined.
This is a follow up of 8b32de2ec9 and this
will fix the following failures:
http://rubyci.s3.amazonaws.com/icc-x64/ruby-master/log/20210505T030003Z.fail.html.gz
```
1) Failure:
TestMkmf::TestConvertible#test_typeof_builtin [/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/test/mkmf/test_convertible.rb:9]:
convertible_int: checking for convertible type of short... -------------------- short
--------------------
convertible_int: checking for convertible type of int... -------------------- int
--------------------
convertible_int: checking for convertible type of long... -------------------- long
--------------------
convertible_int: checking for convertible type of signed short... -------------------- failed
"icc -std=gnu99 -o conftest -I. -I/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/.ext/include/x86_64-linux -I/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include -I./test -O3 -ggdb -Wall -Wextra -Wdeprecated-declarations -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-unused-parameter -Wunused-variable -diag-disable=175,188,1684,2259,2312 -Wextra-tokens -Wundef conftest.c -L. -L/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby -Wl,-rpath,/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-rpath,/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/lib -L/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/lib -lruby-static -lz -lpthread -lrt -lrt -ldl -lcrypt -lm -lm -lc"
In file included from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/defines.h(72),
from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/ruby.h(23),
from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby.h(39),
from conftest.c(1):
/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/backward/2/assume.h(34): warning #193: zero used for undefined preprocessing identifier "HAVE_BUILTIN___BUILTIN_EXPECT"
#if RBIMPL_HAS_BUILTIN(__builtin_expect)
...
```
The recent Termux's clang predefines `__ANDROID_API__` as a fixed number
24. However, when it is lower to the current device version, some
functions that "configure" detemines available are not declared
correctly in the header files.
This change forces to overwrite the predefined `__ANDROID_API__` macro
with the current device version.
ref: https://github.com/termux/termux-packages/issues/6176
Now we require C99, these features available of course.
* prototypes
* stdarg prototypes
* token pasting
* stringization
* string literal concatenation
Major Linux distribution packages including Debian, Ubuntu, and Fedora
use `--compress-debug-sections=no` to build ruby, and then extract and
compress debug symbols as separate files. However, the configure option
makes ruby not link zlib, thus the generated binary cannot uncompress
the compressed separate debug symbol files, and fails to show C level
backtrace when a critical error like segfault occurs.
This change makes ruby always link zlib if it is available so that it
can show C level backtrace correctly.
Related: Debian packages require https://github.com/ruby/ruby/pull/3627
to load debug symbol files.
getaddrinfo_a() gets stuck after fork().
To avoid this, we need 1 second sleep to wait for internal
worker threads of getaddrinfo_a() to be finished, but that is unacceptable.
[Bug #17220] [Feature #17134] [Feature #17187]
We need stop worker threads in getaddrinfo_a() before fork().
This change adds a hook before fork() that cancel all outstanding requests
and wait for all ongoing requests. Then, it waits for all worker
threads to be finished.
Fixes [Bug #17220]
The check output a warning on M1 Mac mini
http://rubyci.s3.amazonaws.com/osx1100arm/ruby-master/log/20201127T074507Z.log.html.gz
```
checking x86intrin.h usability... no
checking x86intrin.h presence... yes
configure: WARNING: x86intrin.h: present but cannot be compiled
configure: WARNING: x86intrin.h: check for missing prerequisite headers?
configure: WARNING: x86intrin.h: see the Autoconf documentation
configure: WARNING: x86intrin.h: section "Present But Cannot Be Compiled"
configure: WARNING: x86intrin.h: proceeding with the compiler's result
checking for x86intrin.h... no
```
The failure initially noticed on `autoconf-2.69d` (soon to become 2.70):
```
$ ./configure
./configure: line 8720: syntax error near unexpected token `fi'
./configure: line 8720: `fi'
```
Before the change generated `./configure ` snippet looked like:
```
if ! $CC -E -xc - <<SRC >/dev/null
then :
#if defined __APPLE_CC__ && defined __clang_major__ && __clang_major__ < 3
#error premature clang
#endif
SRC
as_fn_error $? "clang version 3.0 or later is required" "$LINENO" 5
fi
```
Note the newline that breaks here-document syntax.
After the change the snippet does not use here-document.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Its `__has_declspec_attribute()` is not reliable. For instance,
while `__has_declspec_attribute(noalias)` is true but 'noalias'
attribute is warned as unknown.
It is reported that on a system of i386 System V ABI, GCC returns 8 for
__alignof__(double). OTOH the ABI defines alignments of double to be 4,
and ISO/IEC 9899:2011 reads that _Alignof(double) shall return 4 on such
machine. What we want in ruby is 4 instead of 8 there. We cannot use
__alignof__.
Additionally, both old GCC / old clang return 8 for _Alignof(double) on
such platforms. They are their bugs, and already fixed in recent
versions. But we have to support older compilers for a while. Shall
check sanity of _Alignof.
Availability of `alignas` is checked in include/ruby/internal/stdalign.h
now. That does not need this configure check. Also as commented in the
header, we see `_Alignas` being inadequate for our purpose.
AC_PROG_CXX checks for several C++ compilers INCLUDING g++. When none
of them were found it sets the CXX variable to be g++. This doesn't
make any sense. Absense of g++ has already been made sure.
Because we don't want insanity (that's the whole reason we test the
environment using autoconf), we need to swipe such insane variable out.
The previous attempt to fix this in
b87df1bf24 reversed the argument
order instead of just fixing the quote escaping.
From Takahiro Kambe.
Fixes [Bug #15178]
AC_PROG_CC_C99 calls AC_PROC_CC, which calls _AC_PROG_CC_G, which sets
default CFLAGS, whose contents are not customisable. We don't welcome
this behaviour.
The exact same thing happens for CXXFLAGS in AC_PROG_CXX.
In case of cross-compilation, GCC might provide its own linker. Its
behaviour seems slightly different from that of gcc(1). This is not a
big deal for normal situations, but the difference can cause libtool to
go mad.
We ship bundled libffi for windows users, and libffi uses libtool. If
we use cross-compiler version of gcc instead of its ld conterpart, we
fail to compile fiddle. That should not be what we want.
Historically `$program_transform_name` has been put in front of
`AC_CANONICAL_TARGET`. Previous commit changes it, which affects the
name of generated ruby binary when cross-compiling. I _guess_ the
historical behaviour is a bug (name of ruby binary shall honour --target
configure option I think), but anyways here I preserve that questionable
way.
These days as link-time optimisations spread accross compilers, they
tend to ship their own version of ld, ar, etc. Why not detect such
things if any. Users can select compilers by ./configure --with-gcc=
whatever, or select individual tool by e.g. ./configure NM=whatever.
The added AC_ARG_VAR macros enrich ./configure --help output.
The RubyVM uses C macro defines to feature detect whether
`backtrace(2)` support is available, and if so it includes C level backtraces
when the RubyVM itself crashes.
But on my machine, C level backtraces from `vm_dump.c` didn't work when
using a version of Ruby buillt on the machine, but worked fine when using a
version of Ruby built on another machine and copied to my machine.
The default autoconf test for backtraces uses a sigaltstack size that is
too small, so the SIGSEGV signal handler itself causes a SIGSEGV).
I noticed that signal.c uses a larger sigaltstack size:
https://github.com/ruby/ruby/blob/v2_6_5/signal.c#L568
The specific variables it looks at:
- `HAVE_BACKTRACE`
this is a macro defined by autoconf because there is a line in the
configure script like `AC_CHECK_FUNCS(backtrace)` (see the autoconf
docs for more).
- `BROKEN_BACKTRACE`
this comes from a custom program that Ruby's configure script runs to
attempt to figure out whether actually using backtrace(2) in a real
program works. You can see the autoconf program here.
<https://github.com/ruby/ruby/blob/v2_6_5/configure.ac#L2817-L2863>
It uses sigaltstack and SA_ONSTACK to create a seperate stack for
handling signals.
The problem was: SIGSTKSZ (which comes from a system header!) was not
suggesting a large enough stack size. When checking on an Ubuntu 16.04
box, we found that SIGSTKSZ was 8192 and MINSIGSTKSZ was 2048.
BASERUBY needs to be at least Ruby 2.2 since
46acd0075d.
I think it's better to explicitly fail early as soon as BASERUBY
is used in this case, versus trying to debug later failures.
This modifies things to check both implicitly use of ruby in the
PATH as BASERUBY, and explicitly specified older versions of ruby
when using --with-baseruby.
Fixes [Bug #16668]
Allow the 'Dir.home' method to reliably locate the user's home directory when
all three of the following are true at the same time:
1. Ruby is running on a Unix-like OS
2. The $HOME environment variable is not set
3. The process is not a descendant of login(1) (or a work-alike)
The prior behavior was that the lookup could only work for login-descended
processes.
This is accomplished by looking up the user's record in the password database
by uid (getpwuid_r(3)) as a fallback to the lookup by name (getpwname_r(3))
which is still attempted first (based on the name, if any, returned by
getlogin_r(3)).
If getlogin_r(3), getpwnam_r(3), and/or getpwuid_r(3) is not available at
compile time, will fallback on using their respective non-*_r() variants:
getlogin(3), getpwnam(3), and/or getpwuid(3).
The rationale for attempting to do the lookup by name prior to doing it by uid
is to accommodate the possibility of multiple login names (each with its own
record in the password database, so each with a potentially different home
directory) being mapped to the same uid (as is explicitly allowed for by
POSIX; see getlogin(3posix)).
Preserves the existing behavior for login-descended processes, and adds the
new capability of having Dir.home being able to find the user's home directory
for non-login-descended processes.
Fixes [Bug #16787]
Related discussion:
https://bugs.ruby-lang.org/issues/16787https://github.com/ruby/ruby/pull/3034
GCC/Clang can optimize to calculate `sin(x)` and `cos(x)` at once,
when the both are closely called on the same argument.
Similar optimization is possible for `__sinpi(x)` and `__cospi(x)`
if available, which calculate arguments in radian, i.e.
`sin(x*M_PI)` and `cos(x*M_PI)` respectively.
On some architectures (like RISC-V) sub-word atomics are only available
when linking against -latomic, but the configure script doesn't do that,
causing the atomic checks to fail and the resulting ruby binary is
non-functional. Ruby does not use sub-word atomic operations, rb_atomic_t
is defined to unsigned int, so use unsigned int when checking for atomic
operations.
Nobuyoshi Nakada
Jeremy Evans
Yuta Saito
Alan Wu
John Hawthorn
KJ Tsanaktsidis
Jeremiah Gowdy
Jeremiah Gowdy
Takashi Kokubun
nick evans
Sergey Fedorov
Jun Aruga
Aaron Patterson
Alan Wu
S-H-GAMELINKS
Peter Zhu
Naohisa Goto
Yusuke Endoh
David CARLIER
Lars Kanis
xtkoba (Tee KOBAYASHI)
卜部昌平
Samuel Williams
Benoit Daloze
Kazuhiro NISHIYAMA
Rick Mark
Andrew Aladjev
TAKANO Mitsuhiro
Zoltán Mizsei
Masaki Matsushita
Sergei Trofimovich
Jake Zimmerman
Watson
Alan D. Salewski
Andreas Schwab