Fix autoload status of statically linked extensions
Previously, for statically-linked extensions, we used vm->loading_table to delay calling the init function until the
extensions are required. This caused the extensions to look like they
are in the middle of being loaded even before they're required.
(rb_feature_p() returned true with a loading path output.) Combined
with autoload, queries like defined?(CONST) and Module#autoload?
were confused by this and returned nil incorrectly. RubyGems uses defined? to detect if OpenSSL is available and failed when OpenSSL was
available in builds using --with-static-linked-ext.
Use a dedicated table for the init functions instead of adding them to
the loading table. This lets us remove some logic from non-EXTSTATIC
builds.
Added by alanwu (Alan Wu) over 2 years ago
Fix autoload status of statically linked extensions
Previously, for statically-linked extensions, we used
vm->loading_tableto delay calling the init function until theextensions are required. This caused the extensions to look like they
are in the middle of being loaded even before they're required.
(
rb_feature_p()returned true with a loading path output.) Combinedwith autoload, queries like
defined?(CONST)andModule#autoload?were confused by this and returned nil incorrectly. RubyGems uses
defined?to detect if OpenSSL is available and failed when OpenSSL wasavailable in builds using
--with-static-linked-ext.Use a dedicated table for the init functions instead of adding them to
the loading table. This lets us remove some logic from non-EXTSTATIC
builds.
[Bug #19115]