Gabriela Gibson wrote:
> configure: WARNING: The detected Ruby is too old for Subversion to use
> configure: WARNING: A Ruby which has rb_hash_foreach is required to use the
> configure: WARNING: Subversion Ruby bindings
> configure: WARNING: Upgrade to the official 1.8.2 release, or later
>
> I have never used ruby, but was piqued to check:
>
> $ ruby --version
> ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]
>
> I asked on IRC and breser took a look and thought that the error
> message (and the check routine) could be improved, and that the problem may
> be
> that I haven't got ruby-dev installed.
>
> [23:36] <breser> ruby -r mkmf -e
> 'exit(have_func("rb_hash_foreach") ? 0 : 1)'; echo $?
> [23:39] <breser> cinnamon:
> https://www.opencsw.org/mantis/print_bug_page.php?bug_id=3445
> [23:39] <breser> cinnamon: That might be why, realize that's not
> directly related but it looks like the mkmf test fails if ruby
> static library is missing.
> [23:40] <cinnamon> breser:
> /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require':
> cannot load such file -- mkmf (LoadError) from
> /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
>
> I duly installed ruby-dev, however even after removing it with
> apt-get --purge, configure was still (nearly) happy:
>
> [[[
> checking rb_hash_foreach... yes
> checking for rdoc... /usr/bin/rdoc
> checking for Ruby major version... 1
> checking for Ruby minor version... 9
> checking for Ruby teeny version... 3
> configure: WARNING: WARNING: The detected Ruby is 1.9.3
> configure: WARNING: WARNING: Only 1.8.x releases are fully supported, 1.9.3
> support is new
> checking for swig... none
> configure: Configuring python swig binding
> checking for Python includes... -I/usr/include/python2.7
> checking for compiling Python extensions... i686-linux-gnu-gcc -pthread -fPIC
> checking for linking Python extensions... i686-linux-gnu-gcc -pthread -shared
> -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-
> functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-p
> rotector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> checking for linking Python libraries... -Wl,-O1 -Wl,-Bsymbolic-functions
> -Wl,-Bsymbolic-functions -Wl,-z,relro
> checking for apr_int64_t Python/C API format string... L
> checking perl version... 5014002
> configure: Configuring Ruby SWIG binding
> checking for Ruby include path... -I. -I/usr/include/ruby-1.9.1
> -I/usr/include/ruby-1.9.1/ruby -I/usr/include/ruby-1.9.1/ruby/
> backward -I/usr/include/ruby-1.9.1/i686-linux checking how to compile Ruby
> extensions... gcc -g3 -fno-omit-frame-pointer -fno-inline -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
> -DSVN_DEBUG -DAP_DEBUG
> checking how to link Ruby extensions... gcc -shared -shrext .so checking how
> to
> link Ruby libraries... -lruby-1.9.1 -lpthread -lrt -ldl -lcrypt -lm
> checking for rb_errinfo... yeschecking where to install Ruby scripts...
> /usr/local/lib/site_ruby/1.9.1
> checking where to install Ruby extensions...
> /usr/local/lib/site_ruby/1.9.1/i686-linux
> checking how to use output level for Ruby bindings tests... normal
> checking for ctypesgen.py... none
> ]]]
>
> Note that configure is finding the headers for 1.9.1 here and not
> 1.9.3 as I would have expected, and it looks like apt-get set a
> path correctly which got it to work, but I'm not sure how to
> figure out what it did. Also, I cannot find a way of restoring
> my system to the state that produced the original problem, it
> could well be that the apt-get removal was not as comprehensive
> as it should have been.
Just to throw a little bit of explanation into the mix, the package description
of the "ruby-1.9.1" package, version 1.9.3 (in Ubuntu 12.04) says:
"In the name of this package, `1.9.1' indicates the Ruby library
compatibility version. This package currently provides the `1.9.3'
branch of Ruby, which is compatible with the `1.9.1' branch."
So the Ruby version 1.9.3 packages and files have "1.9.1" in their names.
- Julian
> When I looked at the SWIG site, I found this advice:
>
> quote:
> 32.1.2 Getting the right header files
>
> In order to compile the wrapper code, the compiler needs the
> ruby.h header file. This file is usually contained in a directory
> such as
>
> /usr/lib/ruby/1.8/x86_64-linux-gnu/ruby.h
> /usr/local/lib/ruby/1.6/i686-linux/ruby.h
>
> The exact location may vary on your machine, but the above
> location is typical. If you are not entirely sure where Ruby is
> installed, you can run Ruby to find out. For example:
>
> $ ruby -e 'puts $:.join("\n")'
> /usr/local/lib/ruby/site_ruby/1.6 /usr/local/lib/ruby/site_ruby/1.6/i686-linux
> /usr/local/lib/ruby/site_ruby /usr/local/lib/ruby/1.6
> /usr/local/lib/ruby/1.6/i686-linux .
> --/quote
>
> This command executed on my Ubuntu system gives me:
>
> $ ruby -e 'puts $:.join("\n")'
> /usr/local/lib/site_ruby/1.9.1
> /usr/local/lib/site_ruby/1.9.1/i686-linux
> /usr/local/lib/site_ruby
> /usr/lib/ruby/vendor_ruby/1.9.1
> /usr/lib/ruby/vendor_ruby/1.9.1/i686-linux
> /usr/lib/ruby/vendor_ruby
> /usr/lib/ruby/1.9.1
> /usr/lib/ruby/1.9.1/i686-linux
>
> breser thought that we'd need some kind of test for mkmf that
> doesn't fail, unless mkmf is broken.
>
> I don't know enough to fix this problem, perhaps someone on the
> list knows what is going on here?
>
> thanks,
>
> Gabriela
>
