Build-time DLLs can be different than runtime DLL versions

[larskanis]

What problems are you experiencing?

As discovered in #53 , updates to DLLs, which are bundled with RI2 as builtin DLLs, are not available to the ruby process at runtime. The ruby builtin DLLs are always preferred over any other DLLs. It can therefore happen, that gems are linked against a newer version of the DLL than the one that is loaded at runtime.

Steps to reproduce

• Install RubyInstaller-2.4.1-1-x64 (not the latest version)
• Run ridk install 1 2 3
• Run ridk exec pacman -S mingw-w64-x86_64-openssl
• Run gem install openssl
• Check runtime version: ruby -ropenssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
  => OpenSSL 1.0.2k 26 Jan 2017
• Check build version: ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
  => OpenSSL 1.0.2l 25 May 2017

What's the output from ridk version?

[larskanis]

The current work-around for this kind of issues is to build and install a renewed version of RI2. This automatically ships the latest MSYS2 DLLs, so that builtin DLLs and package DLLs are the same.

A longer term solution would be to change the current side-by-side assembly mechanism, which is used by ruby.exe, in such a way, that it doesn't apply to gems installed after RI2 installation. This should be possible by injecting a RI2 specific XML manifest into all extension so files, which are shipped with the RI2 setup.

[MSP-Greg]

First of all, do OPENSSL_LIBRARY_VERSION & OPENSSL_VERSION have their lookups flipped? 2.4.1-1-x64 was built with 1.0.2k, but after your replacement, it's running on 1.0.2l. Maybe I'm missing something...

Thanks for the responses. I've got some weekend stuff to take care, but I'd like to think about all the different issues and use cases.

This should be possible by injecting a RI2 specific XML manifest into all extension so files

Are you also referring to copying dll files from the MSYS2 folders? Given that MSYS2 only allows one version of a package...

I don't like the idea of multiple MSYS2 installations.

[MSP-Greg]

@larskanis

Okay, now I really gotta run, but I checked some code testing I had done. If in operating_system.rb we change the following:

RubyInstaller::Runtime.add_dll_directory("#{RbConfig::CONFIG['bindir']}/ruby_builtin_dlls")

to:

RubyInstaller::Runtime.add_dll_directory("#{RbConfig::CONFIG['bindir']}/ruby_builtin_dlls")
RubyInstaller::Runtime.enable_dll_search_paths 

Are we causing any issues? It might take care of the specific issue you mentioned (package update, but no ruby changes), don't have time to swap packages, I just renamed MSYS folder...

As I mentioned, I'll collect my thoughts later...

[MSP-Greg]

@larkanis

First of all, guess I was distracted this morning, I missed 'Run gem install openssl ' in your first message.

Anyway, I'm moving between my trunk build, 2.4.1-2, etc.

From what I can tell, the manifest only needs to contain at most one file libgmp-10.dll, which I believe is used by x64-msvcrt-ruby2*0.dll.

The ruby builtin DLLs are always preferred over any other DLLs

I'm too tired to check this further, but I was going crazy because that wasn't what I was finding. But, I think the issue was that I was renaming my MSYS folder. If it's not found, is the ruby_builtin_dlls folder not added to the 'dll path' (and, maybe, no error message)? I was testing EventMachine with OpenSSL, and installed it with 1.0.2, then I reinstalled my 1.1.0 package. Checked for EM, and it found the default OpenSSL 1.0.2 dlls in ruby_builtin_dlls, which wasn't the case with MSYS renamed... Thanks.

[mohits]

Hi @larskanis - do you think we can close this? Or do you feel that this is still pending to resolve?

[larskanis]

This issue is still present, but most of the time it can be fixed by updateing to the latest RubyInstaller release. I didn't find a better solution so far, but maybe in the future. So let it open!

[mohits]

I will check again in a few months :)

[mohits]

Hi @larskanis - in Nov 2022, I promised to check again on this issue in a few months. What do you feel now? :-)