[Rubygems-developers] Question on platform, x64
luislavena at gmail.com
Tue Jan 27 14:01:39 EST 2009
On Tue, Jan 27, 2009 at 4:42 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
>> -----Original Message-----
>> From: rubygems-developers-bounces at rubyforge.org
>> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf
>> Of Luis Lavena
>> Sent: Tuesday, January 27, 2009 10:58 AM
>> To: rubygems-developers at rubyforge.org
>> Subject: Re: [Rubygems-developers] Question on platform, x64
>> On Tue, Jan 27, 2009 at 3:42 PM, Berger, Daniel
>> <Daniel.Berger at qwest.com> wrote:
>> > Hi,
>> > I released sys-proctable 0.8.0 last night. The Linux
>> version has its own source file (pure Ruby), and the
>> resulting gem is called "sys-proctable-0.8.0-x86-linux.gem".
>> However, when I try to install it on a RHEL here at work, it
>> tries to install an older version.
>> Is this a gem with a extension? Or is just pure-ruby code?
> Depends on the platform. For Linux, Windows and Solaris it's pure Ruby. For FreeBSD, HP-UX, OS X and other BSD flavors it's a C extension.
Oh, I see.
>> > I _think_ this is happening because I built it on a x32
>> Linux (Ubuntu) system at home, while the RHEL box here at
>> work are x64. If I build the gem on the RHEL box, for
>> example, I end up with "sys-proctable-0.8.0-x86_64-linux.gem".
>> > I tried installing using "--platform=linux", but that
>> didn't seem to help.
>> "--platform=x86-linux" should work, the same for
>> "x86-mingw32" or "x86-mswin32-60" under Windows.
> Thanks, that worked. For Windows it seems that specifying "--platform=mswin32" was enough to install the VC 6 version on my VC 8 Ruby.
Watch out for CRT memory allocation and freeing. If your extension
(MSVCRT linked) alloc memory your ruby version (MSVCR80) cannot free
>> > That a bug? Or did I miss something? Is there a spec option
>> I can tweak to say "Any Linux Platform"?
>> Originally the platforms are indications of binaries being
>> carried and bundled in the gem, not under which platform the
>> gem should work.
> Well, I'm kind of stuck then. I have pure Ruby versions that will work on a particular operating system, but aren't tied to any particular runtime, bit-ness, etc.
I see the issue, and I see a simple condition around the RUBY_PLATFORM
and CONFIG['host_os'] will not work for you.
There is no way to conditionally tell rubygems that "under this
platform, please build this extension".
> If there isn't any way to specify that with the Gem::Specification, I would argue that we need some way to do so. Or am I the only person in the world hitting this particular issue?
You're not alone, this imposes a problem for other gems too.
As example, there is a json gem. The json gem take advantage of a C
extension to parse json output faster, but it also works without it
with a slower pure-ruby version.
They faced this same problem, and created two gems: json, which forces
the compilation of the extension and json_pure, which doesn't bundle
> PS - Yes, I know I've brought this up before, so sorry if I'm beating the issue to death. If you want to see what I'm dealing with, take a look at the sys-proctable source and tell me how _you_ would bundle the gems.
Beating these issues until death is something good, you've really
exposed another quirk of RubyGems as package manager that needs to be
handled to ensure better cross platform integration.
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
More information about the Rubygems-developers