Checking by `__STDC_VERSION__` is unreliable because old gcc 4.8
supports `-std=gnu11` option but does not implement `_Thread_local`.
Check the implementation directly instead.
The socket extensions rubysocket.h pulls in the "private" include/gc.h,
which now depends on vm_core.h. vm_core.h pulls in id.h
when tool/update-deps generates the dependencies for the makefiles, it
generates the line for id.h to be based on VPATH, which is configured in
the extconf.rb for each of the extensions. By default VPATH does not
include the actual source directory of the current Ruby so the
dependency fails to resolve and linking fails.
We need to append the topdir and top_srcdir to VPATH to have the
dependancy picked up correctly (and I believe we need both of these to
cope with in-tree and out-of-tree builds).
I copied this from the approach taken in
https://github.com/ruby/ruby/blob/master/ext/objspace/extconf.rb#L3
Remove !USE_RVARGC code
[Feature #19579]
The Variable Width Allocation feature was turned on by default in Ruby
3.2. Since then, we haven't received bug reports or backports to the
non-Variable Width Allocation code paths, so we assume that nobody is
using it. We also don't plan on maintaining the non-Variable Width
Allocation code, so we are going to remove it.
ruby/bigdecimal#187 has changed a behavior and ruby/spec also needed a
follow up at 0d8ef62fc2.
However, because bigdecimal is a separate gem and can be updated in
older versions of ruby, `RUBY_VERSION` is not appropriate for this
guard. That means it needs bumped up `BigDecimal::VERSION`.
3a2a7a9353
JRuby has its own implementation of the `openssl` library in
jruby-openssl. The simplest way for us to allow users to set
openssl as a gem dependency is to ship a stub gem that just
depends on jruby-openssl. This patch adds that to the gemspec.
Additional work may be required to fit this stub gem into the test
and release process.
See #20 for more details.
74ccaa5e18
The dependency of extconf.h on bigdecimal.gemspec does not make sense
as far as no rule is defined for it. Also, the relationship between
extension library and gemspec file is various in default gems, and
does not work well.
7f99b28552
* remove false call-seq (output from Ruby parsing is cleaner)
* explain output: argument in plain words
* change parameter name in docs of #dump_shapes (typo)
JRuby currently ships its own internal bigdecimal extension as
part of the core libraries. In order for users to be able to add
bigdecimal to their Gemfile or gem dependencies, we need to stub
out the C extension and just load the extension shipped with
JRuby.
In the future we will try to move our BigDecimal implementation
into the gem, but for now this is the simplest way to make it
installable on JRuby.
See #169829956c643
Right now the attached object is stored as an instance variable
and all the call sites that either get or set it have to know how it's
stored.
It's preferable to hide this implementation detail behind accessors
so that it is easier to change how it's stored.
This version primarily updates the JRuby extension to use
SnakeYAML Engine, a newer version of the SnakeYAML library, which
also updates YAML support to 1.2. The JRuby extension now also
exposes settings for the parser.
6f2b16b343
See jruby/jruby#7570 for some of the justification for this move. We only
require the parser from SnakeYAML, but in the original form it is
encumbered with Java object serialization code that keeps getting
flagged as a CVE risk. We disagree with the assessment, at least
as it pertains to JRuby (we do not use the code in question) but
our inclusion of the library continues to get flagged by auditing
tools.
This commit starts the process of moving to the successor library,
SnakeYAML Engine. The parser API is largely unchanged, except as
seen in this commit. No Java exceptions are thrown, but a number
of Psych tests fail (possibly due to Engine being YAML 1.2 only).
