Injects (possibly outdated) .dlls into system PATH #315

techtonik opened this Issue Apr 5, 2016 · 8 comments


None yet

4 participants


Ruby adds some imporant .dlls into system PATH:


Which creates some unusual compatibility problems:
wesnoth/wesnoth#616 (comment)

For comparison Git for Windows only adds .exe and msys-2.0.dll files.

Azolo commented Apr 7, 2016

So, yes we do in fact dynamically link against those because those are ‘stdlib` libraries and don't need to be loaded all the time.

As for being outdated, also probable. They have to be updated manually, and I barely have time to get a release out.

So, I guess the question is, what kind of solution are you looking for?


@Azolo I am not sure, but it might be that Git executable uses hardcoded relative paths to locate the libraries and dynamically load them.

Azolo commented Apr 7, 2016

I can't remember the exact lookup order, but I'm pretty sure that libraries in the executable's folder get looked at before we go looking on the PATH for anything. Which is why if you run ruby when it's not in the PATH the stdlib loading should still work.

But I thought the Git installation got around it by having a cmd folder that is just a script wrapper around the executable.

Which won't work for us in the sane way because of gems.


I don't get why gems can not be loaded dynamically.


It is possible to redirect DLL loading using application manifests. (See

That way it is possible to dump all Ruby DLLs into a separate folder outside the PATH and then load them via DLL redirection. It would require no change to the Ruby source code, but the installer and most likely some rubyinstaller tasks have to be changed...

Azolo commented Apr 7, 2016

@techtonik gem binstubs have to be loaded into a folder in the path, and Ruby has some expectations with those gem files. In the past we've played with the idea of moving gems into a couple different places. I could never get things to work as expected after doing that though, which also doesn't solve your root problem here.

@daniel-rikowski Those are for Visual Studio linked binaries and look like they come with their own problems. I don't think anything like that would be easily accomplished with mingw.


Those are for Visual Studio linked binaries

That is not 100% correct. True, Visual Studio can auto-generate a manifest, but that doesn't mean it is a VS-only feature or requires a VS runtime library. Any .exe can have a manifest file. Windows itself performs the necessary operations. (Since Windows XP)

look like they come with their own problems

As always 😄

I don't think anything like that would be easily accomplished with mingw.

As long as MinGW executables use LoadLibrary, it should work. But granted, manually creating manifest files is a tedious job, especially since they are sparsely documented.

There are other ways to get a private DLL folder, for example SetDllDirectory. Unfortunately that would require a patch to the Ruby source code. I don't know how difficult that is, considering the current build process and the internal workings of Ruby.

PS: Here is a great summary on how Windows finds DLLs and how it can be affected:

golirev commented May 21, 2016

I created a PR.
See #322

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment