[Rubygems-developers] Binary distribution
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