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

Charlie Savage cfis at savagexi.com
Mon Jul 21 16:16:19 EDT 2008

> Yes, but also exposes issues and clashes if some gem bundles a dll
> like OpenSSL which proven to clash with the openssl bindings. There is
> a example of that scenario when running postgresql adapters, the
> bundled openssl dll and trying to require 'openssl' library.

> I saw that Ruby C openssl built/linked to a older version of openssl
> (the one in ruby/bin) produce some errors when postgresql bundled dlls
> precede in the PATH.

If the dlls have the same name, but are different versions, and both are 
used in the same process, then yes you'd have an issue for that process. 
  But in the copying solution you have an even worse problem - you would 
have permanently broken one of the GEMS forever by overwriting its dll. 
  So I still see the copying solution is higher risk.  I agree there is 
no great solution here though.

Here is another example.  Libxml2.dll requires libiconv.  Ruby already 
has one, but libxml is using a newer one.  Different files name for now 
though, so no conflict.  But I'd hate to intall libxml and have it 
overwrite Ruby's iconv by mistake.

>> Remember, this path manipulation is only for the currently running process
>> (not system wide) and is fully supported by the Windows api. Don't know
>> about other OSes though, haven't looked.

> That means make RubyGems Ruby/DL dependant and include the
> SetDllDirectory API. I'm not against that, but we need to know how
> deep those modifications go.

Actually this works (at least on Windows):

ENV['PATH'] += 'path to library'

So actually you don't need the dependency on SetDllDirectory. But yes, 
point taken.  If you need to use SetDllDirectory, there would be a gem 
dependency on Win32API.

>>>>> What about #binaries? and we thread them different that executables
>>>>> (verbatim copy them instead of adding shebangs).
>>>> I'd probably be more specific and define a new spec setting called
>>>> "libraries" that means RubyGems will:
>>> But a library is also a ruby library, which doesn't apply. Is it a
>>> binary dependency of the extension bundled in the gem.
>> Yes.  But there is a difference between a binary executable and a binary
>> library.  I think we would regret calling them the same thing, because they
>> are not.
> Is better we find sooner a name to make them fit properly sooner than later :-)

Yes :)

I'd have 2 things, executables and libraries.  But if we decide to 
combine them, then your suggestion of binaries is good.

>>>> GemSpec:
>>>> spec.libraries << "lib/libxml2-2.dll"
>>>> How does that sound?
>>> Hmn, that definetely add some platform specific code beyond what
>>> RubyGems should be doing... and from POV I don't like it so much.
>> Why is that platform specific code?  Any file listed in libraries gets
>> copied to ruby/bin.
> SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case?

Oh, sorry.  I was thinking of the case that files added to spec.libaries 
are copied to ruby/bin.  Or if we did the PATH thing, then ENV['PATH']

But that raises a good point.  Whether we copy the files or manipulate 
the path, from a GEM developer point of view they will still be 
specified in the same way (spec.libraries, spec.binaries, 
spec.exetuables, or whatever we call them).  Note that here is an 
example of why having spec.executable and spec.libraries is better than 
just spec.binaries.  In the first case, you have to copy executables to 
ruby/bin but in the second you do not.

>> Of course, you might not want that to happen on all platforms, but to solve
>> that you just provide platform specific gems (which obviously you have to
>> anyway if the GEM include binary files).  For a Windows GEM you'd include
>> the spec.libraries line, for other platform GEMS you would not.
> I'll love to heard back from Eric and other RubyGems developers about this.


>>> Indicate your users to copy the dll or provide a RubyGems binary
>>> (minimal script) that performs the dll copy form that particular
>>> folder into ruby/bin (Gem.bindir)
>> Right - which is what we do now in the documentation.  I think that's a bad
>> solution and want to avoid it.
> We agree :-P
>>> Something similar is what I do for mongrel_service.
>> Services are a bit different, in that you need admin rights to install.
> Oh, I was not talking about installing services, I was talking about
> mongrel_service use a small script to copy mongrel_service executable
> into ruby/bin directory.

Ah, I see.

> (I need to improve my english)

Your English seems great to me :)

Thanks for all your ideas and feedback, it really helps.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080721/1083a6e7/attachment.bin>

More information about the Rubygems-developers mailing list