[Rubygems-developers] Binary distribution

Chad Fowler chad at chadfowler.com
Wed Dec 3 15:17:58 EST 2003

On Wed, 3 Dec 2003, Lyle Johnson wrote:

# On Dec 2, 2003, at 9:10 PM, Chad Fowler wrote:
# > Anyone have any concrete ideas of what might go wrong if we were to 
# > try to
# > do binary distributions?
# First of all, let me say that if there is a way to make this work, I'm 
# all for it. However, there are a few variables to consider when you 
# start dealing with binary distributions of C/C++ extensions for Ruby.

I would really like it to work too.  Yesterday I installed FreeBSD.  After 
installing it (it came with ruby), I did:

pkg_add -r ruby-rss

It download and installed my now defunct ruby rss module, XMLParser, and 
expat.  ruby -rrss 'p RSS::Channel.new' worked immediately afterward.  It 
would be wonderful if RubyGems could provide this for any platform.

# One variable is the version of Ruby for which the extension was 
# compiled. For example, an extension module compiled against the Ruby 
# 1.8.0 header files and linked against its library may not work with a 
# Ruby 1.8.1 installation, depending on how much has changed in Ruby's C 
# API. This is a problem for all platforms (Windows, Linux/Unix and Mac 
# OS X).

Good point.  We can obviously get easy access to the version of ruby that 
the installer is using.  We don't currently track which version of Ruby a 
gem requires.  One way we could do this is by installing a gem called 
"Ruby" and using the exisitng dependency code.  Shouldn't be too hard from 
a technical implementation perspective, but it might be a bit hairy in 
just determining which versions are compatible.  I haven't done a lot of C 
extension programming I must confess.

# Another variable for C++-based extension modules (on Linux, anyways) is 
# which version of g++ was used to compile the extension. This has been a 
# problem in the past because the g++ application binary interface (ABI) 
# seemed to change for every release of g++. Now, supposedly the ABI is 
# stable at this point and this should be less of a problem in the 
# future, but I've been burned by this too many times in the past not to 
# mention it.

Any ideas on how to get around this?  Is there a way to find out from 
within Ruby which g++ something was built with?  I'm absolutely clueless 
as to what the solution might be on this.


More information about the Rubygems-developers mailing list