Bug #19143: Windows - bundled extension gems compile, but don't copy *.so files to lib folder

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN

[MSP-Greg (Greg L)]

Just finished updating ruby-loco's mswin build to use a system similar to the ucrt & mingw builds.

Confirmed something I noticed previously, and also occurs with the RubyInstaller2 head build.

On Windows, bundled extension gems (debug, rbs) compile their extension in the ext folder, but do not copy them to the lib folder. So, the *.so file is created, but not copied.

I think this was working correctly on Ruby 3.1?

[alanwu (Alan Wu)]

Does that mean the native extensions of those gems don't work when one tries to load them after installation?

[MSP-Greg (Greg L)]

@alanwu (Alan Wu)

Thanks. A bit of 'multi-tasking brain freeze' going on this morning.

Or, yes they do work without a copy in the lib folder.

Please close...

[alanwu (Alan Wu)]

• Status changed from Open to Closed

[nobu (Nobuyoshi Nakada)]

It is intended.
*.so files are architecture-dependent, which are "tainted" in other words, while lib directories are architecture-independent, "untainted".
"Tainted" files should not infect "untainted" directories.

[MSP-Greg (Greg L)]

@nobu (Nobuyoshi Nakada)

Yes, I agree, it might be very helpful when one has more than one platform installed and uses --user-install. As in Gem.install_extension_in_lib, also Gem::Ext::ExtConfBuilder. I overwrite my Windows Ruby master installs daily, so I always use --user-install.

Maybe issues with existing extension gems that load with require_relative, and also pre-compiled gems?