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.
To this date there is no way for Oracle developer Studio to suppress
warnings about unreachable codes (12.6 manual says it implemented
__builtin_unreachable "as a no-op to C++. It might be added to C.")
There is no way but globally kill the warning.
Every time a pointer to/from VALUE conversion happens, these two
warnings are issued:
- warning #1684: conversion from pointer to same-sized integral type (potential portability problem)
- warning #2312: pointer cast involving 64-bit pointed-to type
Thank you, but we are well aware of the "potential portability problem".
Let us ignore them all.
C++ keyword `nullptr` represents a null pointer (note also that NULL is
an integer in C++ due to its design flaw). Its type is `std::nullptr_t`,
defined in <cstddef> standard header. Why not support it when the
backend implementation can take a null pointer as an argument.
ISO/IEC 9899:1999 section 6.5.7 states that "If the value of the right
operand is negative or is greater than or equal to the width of the
promoted left operand, the behavior is undefined". So we have to take
care of such situations.
This has not been a problem because contemporary C compilers are
extraordinary smart to compile the series of shifts into a single
ROTLQ/ROTRQ machine instruction. In contrast to what C says those
instructions have fully defined behaviour for all possible inputs.
Hence it has been quite difficult to observe the undefined-ness of such
situations. But undefined is undefined. We should not rely on such
target-specific assumptions.
We are fixing the situation by carefully avoiding shifts with out-of-
range values. At least GCC since 4.6.3 and Clang since 8.0 can issue
the exact same instructions like before the changeset.
Also in case of Intel processors, there supposedly be intrinsics named
_rotr/_rotl that do exactly what we need. They, in practice, are absent
on Clang before 9.x so we cannot blindly use. But we can at least save
MSVC.
See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157https://bugs.llvm.org/show_bug.cgi?id=17332
MJIT with ccache has a problem on docker environment, so
we need to use original CC (/usr/bin/gcc, for example).
Ubuntu system provides /usr/lib/ccache/gcc and so on to use
gcc with ccache. It is easy to setup ccache by adding
/usr/lib/ccache to $PATH. However we need to use /usr/bin/gcc
(and so on) for MJIT_CC. We can specify MJIT_CC option at
configure, but specifying them is troublesome.
This patch choose original $CC (/usr/bin/gcc, for example)
if $CC is /usr/lib/ccache/$CC.
The use of RUBY_WERROR_FLAG causes this test to fail on OpenBSD
platforms that use the binutils linker (ld.bfd) instead of the
llvm linker (ld.lld), due to warnings added to the binutils linker
in OpenBSD.
Removing the RUBY_WERROR_FLAG would probably also fix it, but that
would affect other platforms.
This should also be backported to Ruby 2.7.
Analysis and similar fix recommended by George Koehler.
With these macros implemented we can write codes just like we can assume
the compiler being clang. MSC_VERSION_SINCE is defined to implement
those macros, but turned out to be handy for other places. The -fdeclspec
compiler flag is necessary for clang to properly handle __has_declspec().
On cross-compilation, compiled binary can no be created because
compiled binary should be created by same interpreter (on cross-
compilation, host ruby is used to build ruby (BASERUBY)).
So that cross-compilation system loads required scripts in text.
It is same as miniruby.
Downstream C++ projects that compile with C++11 or newer and include
the generated config.h file issue compiler warnings. Both C and C++
compilers do string-literal token pasting regardless of whitespace
between the tokens to paste. C++ compilers since C++11 require such
spaces, to avoid ambiguity with the new style of string literals
introduced then. This change fixes such projects without affecting
core Ruby.
icc_version was wrongly defined as "__ICC" on non-icc C compiler, which
caused a warning:
```
./configure: line 8211: test: __ICC: integer expression expected
```
This change adds a sed commend to delete "__ICC".
The icc_version guessing was accidentally disabled because of
61885c9b7ca8ccdaf53d7c365fbb86bad3294d88; `AC_PROG_CC_C99` changes
CC like "icc -std=c99", and `AS_CASE(["x$CC"], [xicc],` does not match.
The variable `icc_version` is eventually defined, so the `AS_CASE` is
not needed. This change removes the `AS_CASE`.
This approach is simpler than the previous approach which tries to
emulate realpath(3). It also performs much better on both Linux and
OpenBSD on the included benchmarks.
By using realpath(3), we can better integrate with system security
features such as OpenBSD's unveil(2) system call.
This does not use realpath(3) on Windows even if it exists, as the
approach for checking for absolute paths does not work for drive
letters. This can be fixed without too much difficultly, though until
Windows defines realpath(3), there is no need to do so.
For File.realdirpath, where the last element of the path is not
required to exist, fallback to the previous approach, as realpath(3)
on most operating systems requires the whole path be valid (per POSIX),
and the operating systems where this isn't true either plan to conform
to POSIX or may change to conform to POSIX in the future.
glibc realpath(3) does not handle /path/to/file.rb/../other_file.rb
paths, returning ENOTDIR in that case. Fallback to the previous code
if realpath(3) returns ENOTDIR.
glibc doesn't like realpath(3) usage for paths like /dev/fd/5,
returning ENOENT even though the path may appear to exist in the
filesystem. If ENOENT is returned and the path exists, then fall
back to the default approach.
Yuta Saito
Nobuyoshi Nakada
Alan Wu
Aaron Patterson
David CARLIER
Jeremy Evans
Lars Kanis
xtkoba (Tee KOBAYASHI)
卜部昌平
Samuel Williams
John Hawthorn
Peter Zhu
Yusuke Endoh
Benoit Daloze
Kazuhiro NISHIYAMA
Rick Mark
Andrew Aladjev
TAKANO Mitsuhiro
Naohisa Goto
Zoltán Mizsei
Masaki Matsushita
Sergei Trofimovich
Jake Zimmerman
Watson
Alan D. Salewski
Andreas Schwab
Paul Jordan
Takashi Kokubun
Koichi Sasada
Matt Valentine-House
Mark Abraham
Lars Kanis