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
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.
Takashi Kokubun
Alan Wu
Maxime Chevalier-Boisvert
Nobuyoshi Nakada
Sergey Fedorov
Jeremy Evans
Kenta Murata
Yuta Saito
John Hawthorn