Skip to content
  • Alan Wu's avatar
    790cf4b6
    Fix autoload status of statically linked extensions · 790cf4b6
    Alan Wu authored
    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.
    
    [Bug #19115]
    790cf4b6
    Fix autoload status of statically linked extensions
    Alan Wu authored
    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.
    
    [Bug #19115]
Loading