[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 2210][RFC] How about /branches/svn-ruby?

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2005-02-19 17:25:54 CET

Garrett Rooney wrote:

> I'm happy to report that I was finally able to get this to work. For
> some reason the libruby1.8 that my Linux distribution installed was not
> exposing rb_hash_foreach (nm /usr/lib/libruby1.8.a | grep
> rb_hash_foreach showed it as defined, but not exposed), so whenever I
> ran the tests I'd get a relocation error. Building against a locally
> built version of Ruby worked fine though, and all tests are passing.

Ok, I figured the rb_hash_foreach problem out.

In Ruby 1.8.1 rb_hash_foreach was declared as static, not exported from
hash.c, so we wouldn't be able to use it. In Ruby 1.8.2 it was changed
slightly and exported, so we can use it. In both cases it's still
defined in intern.h which is included by ruby.h, so you can compile code
that tries to use it just fine, it'll just fail at link time.

But wait, there's more!

I actually have a version of Ruby that claims to be ruby 1.8.2 (at least
according to ruby -v), so why doesn't it work for me? Well, dpkg -l
will tell a different story, I don't have ruby 1.8.2, I actually have
ruby 1.8.1+ruby1.8.2presomethingorother, so it's really 1.8.1 plus
random patches from 1.8.2, it just happens to LIE and say it's 1.8.2, so
we can't even have a simple 'you must have ruby 1.8.2 to use these
bindings' check, it'll fail in reasonably common cases (like where
people are using these particular debian based packaged versions of ruby).

So the easy thing to do is to add a check to configure that turns off
the ruby bindings if we're using ruby 1.8.1 or earlier, since it can't
possibly work in those cases. The better thing to do would be to write
a test that tries to compile and link a program that uses
rb_hash_foreach and see if that works, because even if ruby claims to be
1.8.2 it still might not be sufficient for our needs.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 19 17:27:23 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.