The simple names in `default_exclude_exts` do not match extension
paths under gems.
Extract each gem name from the gemspec file at the top level of each
gem directory. For example, if `ext` is `syslog-0.1.2/ext/syslog/`,
find out `syslog-0.1.2/syslog.gemspec` and take the base name `syslog`
without the suffix `.gemspec`.
The extension library has each initialization function named "Init_" +
basename. If multiple extensions have the same base name (such as
cgi/escape and erb/escape), the same function will be registered for
both names.
To fix this conflict, rename the initialization functions under sub
directories using using parent names, when statically linking.
So different timestamps for different paths will be used. Extentions
paths in bundled gems contain `ruby_version`, which includes the ABI
version, and the same timestamp file for different paths resulted in
build failures when it changed.
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.
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
When configuring with `--disable-rpath` and `--static-linked-ext` (e.g.
building for WASI), `extmk.rb` doesn't build exts under bundled gems,
and `.bundle/gems/#{gemname}-#{ver}` are not created due to no call of
`extmake`.
b249178398 starts creating symlink at
`.bundle/gems/#{gemname}-#{ver}/lib`, but the parent dir is not created,
so configuration aginst debug and rbs gems were failed.
The default gems have not been installed yet in the build directory,
bundled gems depending on them can not work. As those dependencies
should be usable there even without rubygems, make temporary gemspec
files without the dependencies, and use them in the build directory.
* ext/extmk.rb: split notes into header and footer, which are
common, from bodies which are unique for each extensions.
* template/exts.mk.tmpl: now each notes are not one line, should
not unique.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58425 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/extmk.rb: fail if a mandatory extension library failed to
configure. [ruby-core:80759] [Feature #13302]
* template/exts.mk.tmpl: move `exit` at the end.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58412 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Point to the mkmf.log if configuring an extension fails so that people
can find and fix the culprit easily. [ruby-core:80131] [Feature #13302]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58404 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/extmk.rb (parse_args): --command-output is now mandatory.
remove direct build mode.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57448 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/extmk.rb (extmake): fix up r57424 for static-linked-ext.
separate maybestatic argument from basedir which is given always
now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57441 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/configure-ext.mk: configure each directories underneath ext
in parallel.
* template/exts.mk.tmpl: then collect the results.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57401 b2dd03c8-39d4-4d8f-98ff-823fe69b080e