Project

General

Profile

Actions

Bug #19143

closed

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

Added by MSP-Greg (Greg L) over 1 year ago. Updated over 1 year ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:110867]

Description

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?

Updated by alanwu (Alan Wu) over 1 year ago

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

Updated by MSP-Greg (Greg L) over 1 year ago

@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...

Actions #3

Updated by alanwu (Alan Wu) over 1 year ago

  • Status changed from Open to Closed

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

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.

Updated by MSP-Greg (Greg L) over 1 year ago

@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?

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0