[Rubygems-developers] How to deal with binary dependencies?

Luis Lavena luislavena at gmail.com
Mon Jul 21 14:24:27 EDT 2008

On Sat, Jul 19, 2008 at 10:18 PM, Charlie Savage <cfis at savagexi.com> wrote:
> I'd like to revisit a thread from last year:
> http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html
> The problem is how to deal with binary dependencies within a GEM file. I
> think I've come up with a solution, and just posting here for anyone i the
> future that runs into the same problem.

Hey Charlie, I'll snip your message and focus on the issues... :-)

> When a user does require 'libxml' what happens:
> 1.  libxml.rb is loaded
> 2.  libxml.rb loads libxml_ruby.so
> 3.  libxml_ruby.so loads libxml2-2.dll
> Its this third step that causes the issue.  Windows must be able to find
> libxml2-2.dll.  This is explained here:
> http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
> Which basically means:
> * The current directory (where the Ruby program is)
> * In the Windows system directory or PATH
> * In the root directory of the executable.  Since that's ruby.exe, that
> would be ruby/bin
> The Ruby one-click installer goes with the third choice - its puts all its
> dlls in that directory (iconv.dll, libexpat.dll, readline.dll, gdbm.dll,
> etc.).

Yes, that was to avoid user needing to add another folder to they
PATH, and one that is really long (like i386-msvcrt ...)

> Phew, got all that?
> So after playing around with this a  bit I see a few possible solutions:
> *  Have GEMS support the need to move binary dependencies into the ruby/bin
> directory on Windows.  Same issue could happen on other OS's in theory, but
> you usually install libraries like libxml2 system wide. This is recommended
> practice by MSFT
> (http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx - see last
> paragraph).

Last paragraph states:

"It is good practice to install application DLLs in the same directory
that contains the application, even if you are not using DLL
redirection. This ensures that installing the application does not
overwrite other copies of the DLL and cause other applications to
fail. Also, if you follow this good practice, other applications do
not overwrite your copy of the DLL and cause your application to

So, that means is good to put the DLLs in ruby/bin, like One-Click
Installer is doing.

Before 0.9.5 and 1.0 release I tried to invest a bit on the method to
determine when a file is binary or not.

Right now RubyGems offer you a mechanism that set stubs in ruby/bin,
but that procedure doesn't like executables or even shared libraries


> *  Have GEMS support the need to move binary dependencies into the
> site_ruby/1.8/i386-msvcrt directory and tell the user that they have to put
> that directory on the Windows path.  The problem with this of course is a)
> the extra user required step b) its opposite the precedent set by the one
> click install.
> * Modify the PATH on the fly.  This can be done by setting ENV['path'] or
> SetDllDirectory
> (http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx).  From
> testing, this solution in fact does work (I wasn't sure if it would).
> Thoughts?  And more questions.  Should this be standardized?  Should there
> be a libs directory for dlls in gems?  Or should we reuse lib? Should there
> be an option to set the path for Windows?  Should there be the ability to
> check if the dll is already present (sort of like setup.rb does, but not
> using the C compiler, using LoadLibrary instead)

Since we already have #executables and #bindir to define where those
are inside our gems.

What about #binaries? and we thread them different that executables
(verbatim copy them instead of adding shebangs).

Then we can have them inside our gem folder lib ('lib/libxml2-2.dll')
and be able to remove that when the gem involved get's also removed.


Luis Lavena
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

More information about the Rubygems-developers mailing list