When `--conservative` is passed, explicit unlocks are set for top level
gems via `@unlock[:gems]`, so that only those particular gems are
allowed to be updated.
When we compute the "base resolve" from the lockfile (the set of gems
whose versions should be kept pinned by the resolver), we always exclude
gems explicitly unlocked through `@unlock[:gems]` from it. This is done
by the `converge_specs` method.
However, the `converge_specs` method is also used for figuring out
additional lower bound requirements from the lockfile. But in this case,
even if gems are explicitly unlock in `@unlock[:gems]`, we still want to
add the additional requirement, so that gems are not downgraded by the
resolver.
So the solution is to move the line filtering out gems in
`@unlock[:gems]` from the `converged_specs` method out of that method,
so that it only applies for computing the "base resolve", but not the
addtional lower bound requirements.
405119bd7b
It's explicitly loaded when monkeypatching RubyGems, which we do very
early. So neither autoloading it, nor explicitly loading it anywhere
else is necessary.
fbc7a57161
Attempting to install a gem published as both *-linux and *-linux-musl
results in the incorrect gem being picked up, causing build failures due
to binary incompatibility. This is caused by the `nil` wildcard
swallowing the libc information upon version comparison.
Handle the linux case by performing only non-wildcard equality on the
version and asserting 'gnu' and nil equivalence, while preserving the
current behaviour for other OSes.
9eead86abc
Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
e4e054e3ce used four footnotes
without blank lines. And the ChangeLog generated from that commit
resulted in ``undefined method `parts' for nil`` error.
For now, let a footnote terminated by the next footnote mark.
Also refined the error message when undefined footnote is used.
a7f290130b
This is a regression from a change intended to raise errors when user
puts a gem under an incorrect source in the Gemfile by mistake. To fix
the issue, we revert the change that caused it and implement it in a
different way that restores the resolver independency from real
specifications. Now it deals only with names and versions and does not
try to materialize anything into real specifications before resolving.
d2bf1b86eb
For the macOS -bundle_loader linker option, we need a path to the
Ruby exectuable. $(RUBY) is not necessarily a path since it could
be a command line invocation. That happens during build with
runruby.rb and can happen post installation if the user passes
the --ruby option to a extconf.rb. Use $(bindir) to locate
the executable instead.
Before installation, $(bindir) doesn't exist, so we need to be
able to override $(BUILTRUBY) in such situations so test-spec
and bundled extensions could build. Use a new mkmf global,
$builtruby, to do this; set it in fake.rb and in extmk.rb.
Our build system is quite complex...
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
It should be an alias of `--filter-strict`.
`--update-strict` is essentially a dummy option with no special behavior
associated and should be deprecated.
ec1e5d83c8
Do dependency filtering and materialization in one step. Before,
dependency filtering would not consider ruby metadata so it would
discard variants that end up not being materializable in the end.
0c0d40d417
Co-authored-by: Ian Ker-Seymer <ian.kerseymer@shopify.com>
