7.3 unable to load ruby 1.9.2?

[Jon]

I successfully build gvim with dynamic ruby support on a Win7 32-bit system using the mingw ruby and gcc 4.5.0 from http://rubyinstaller.org/downloads and the following simple Make_mingw.mak mods:

-#RUBY=c:/ruby
+RUBY=c:/ruby192
ifdef RUBY
ifndef DYNAMIC_RUBY
DYNAMIC_RUBY=yes
endif
# Set default value
ifndef RUBY_VER
-RUBY_VER = 16
+RUBY_VER = 191
endif
ifndef RUBY_VER_LONG
-RUBY_VER_LONG = 1.6
+RUBY_VER_LONG = 1.9.1
endif

However, ":echo has('ruby')" returns 0 and ":ruby puts 'Hello'" returns

E448: Could not load library function rb_str2cstr
E266: Sorry, this commands is disabled, the Ruby library could not be loaded.

Running ":version" shows "+ruby/dyn" and -DDYNAMIC_RUBY_DLL="msvcrt-ruby191.dll" and PATH has C:\ruby192\bin containing msvcrt-ruby191.dll

Any ideas on what's going wrong?

Jon

[Leonardo Valeri Manera]

Something very similar happens when compiling 7.3.003 against 1.9.2
using MSVC10/MSSDK-7.1 - the static build obviously fails with a
slightly different

if_ruby.obj: error LNK2001: unresolved external symbol __imp__ruby_errinfo

Cheers,
Leo

[Tony Mechelynck]

Ruby 1.9.1 or Ruby 1.9.2? Or did you compile with the *.h include files
of 1.9.2 (from C:\ruby192\include or wherever) and try to run with the
1.9.1 DLL?

Best regards,
Tony.
--
Arithmetic is being able to count up to twenty without taking off your
shoes.
-- Mickey Mouse

[Leonardo Valeri Manera]

1.9.2 is library-compatible with 1.9.1, so internal version of 192 is
191, it names libraries with 191, and stuff is installed under 1.9.1

Cheers,
Leo

[Jon]

> Ruby 1.9.1 or Ruby 1.9.2? Or did you compile with the *.h include files
> of 1.9.2 (from C:\ruby192\include or wherever) and try to run with the
> 1.9.1 DLL?
>

Compiled with 1.9.2's *.h and the only Ruby DLL on PATH is the 1.9.2 DLL named msvcrt-ruby191.dll

As Leo replied, 1.9.2 is "library compatible" with 1.9.1 so the key is to point RUBY to the 1.9.2 root dir but then view RUBY_VER and RUBY_VER_LONG as a library compatibility version since the source directories on 1.9.2 use 1.9.1.

Interesting, I know, it tripped me up on early compile attempts with strange errors, but here's ruby-core's FAQ entry in their 1.9.2 announcement http://www.ruby-lang.org/en/news/2010/08/18/ruby-1-9-2-is-released/

I haven't had a chance to look at if_ruby.c starting here http://code.google.com/p/vim/source/browse/src/if_ruby.c#412

[Jon]

> I haven't had a chance to look at if_ruby.c starting herehttp://code.google.com/p/vim/source/browse/src/if_ruby.c#412

Who maintains if_ruby.c and how do we get that person feedback?

From a brief look, I'll bet the root of this issue that
http://code.google.com/p/vim/source/browse/src/if_ruby.c#310 contains
pointers to functions no longer exported by the ruby dll and
http://code.google.com/p/vim/source/browse/src/if_ruby.c#429 unloads
the ruby dll thereby making it look like the dll was never found.

Also, updating if_ruby.c to abstract the dll loading api as done in
http://code.google.com/p/vim/source/browse/src/if_lua.c#45 would be a
good thing.

Jon

[Jon]

I've got a patch that's working for me on Win7 32-bit using Ruby 1.9.2
from the MinGW 4.5.0 built http://rubyinstaller.org/ After a bit more
testing I'll post it for your consideration.

Jon

[tux.]

Leonardo Valeri Manera schrob am 22.08.2010 16:39:

Something very similar happens when compiling 7.3.003 against 1.9.2
using MSVC10/MSSDK-7.1 - the static build obviously fails with a
slightly different

if_ruby.obj: error LNK2001: unresolved external symbol __imp__ruby_errinfo

For me, it already breaks in if_ruby.c.
VS2010, Win7 32-bit.

GTK that it's not me.

[Jon]

I've tested the following patch for download [1] works so far with the
Ruby for Windows 1.8.7p302, 1.9.1p430, and 1.9.2p0 from http://rubyinstaller.org
on a Win7 Ultimate 32-bit system using MSys/MinGW/TDM 4.5.0 or LLVM-
GCC 2.7. I haven't tested on my Ubuntu system and it's unlikely I
find the time to do so.

The problem was the 'rb_str2cstr' api first deprecated in Ruby 1.7.1
and finally removed in 1.9.2p0. The fix was do ifdef in the
replacement 'rb_string_value' api which was first available in Ruby
1.7.1. Additionally, I injected the same cross-platform dll/so
loading code used in the if_lua.c and if_python.c code. This *should*
work on Ruby 1.6+.

Please review, test, and let me know what further mods are needed.

Jon

[1] http://gist.github.com/546039

[tux.]

Jon schrob am 24.08.2010 02:27:

Please review, test, and let me know what further mods are needed.

:s I am currently trying to get my Ruby installation working again. It "can't find inttypes.h" although I defined HAVE_INTTYPES_H as 0. Despairing.
(I know I had it working with Ruby 1.9.1, damn.)

[Leonardo Valeri Manera]

Make sure you're not crossing the headers - if you're compiling with
mingw you must point it @ i386-mingw32 ruby headers, otherwise is at
i386-mswin32.

So long as its a dynamic build of vim, all that matters is that you
have the right includes /for the compiler you're building vim with/,
so you can use mswin32 includes to link to mingw ruby and vice-versa.
Just steal the includes you don't have (the whole arch folder) and
just put in with the other.

Cheers,
Leo

[tux.]

Leonardo Valeri Manera schrob am 24.08.2010 02:54:

Make sure you're not crossing the headers - if you're compiling with
mingw you must point it @ i386-mingw32 ruby headers, otherwise is at
i386-mswin32.

Ahhhh, one fine day I'll set up my printer and print this on a very, very huge sheet of paper... :-/
Got it, thanks once more ...

With the matching mswin32 build, all is fine (again). Whew...
Bookmarked it now to avoid any further confusion on my side, like when Ruby 1.9.3 comes out ...

Anyway: Jon's patch seems to work for me.
After applying it, :ruby puts("Hello") echoes "Hello" correctly. :-)
(with DYNAMIC_RUBY)

Regards.

[Jon]

bump...

any feedback from a core committer as to whether this patch is
acceptable to be merged into default?

[John Beckett]

Jon wrote:
> any feedback from a core committer as to whether this patch
> is acceptable to be merged into default?

Bram (see :help credits) is the Vim developer. It's an awkward
time currently because Bram was super busy preparing the Vim 7.3
release over the last few weeks, so if there is no response now,
I think it would be best to raise the matter again, starting
from scratch, in say two weeks.

John

[Bram Moolenaar]

Jon Maken wrote:

This patch has made it possible to load Ruby dynamically on Unix.
However, there is no patch for configure, thus one can't actually do
this. Can somone make a patch for configure to load Ruby dynamically?

--
I have to exercise early in the morning before my brain
figures out what I'm doing.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[James Vega]

On Wed, Oct 20, 2010 at 12:19 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> This patch has made it possible to load Ruby dynamically on Unix.
> However, there is no patch for configure, thus one can't actually do
> this.  Can somone make a patch for configure to load Ruby dynamically?

Attached.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>

[Bram Moolenaar]

James Vega wrote:

> > This patch has made it possible to load Ruby dynamically on Unix.
> > However, there is no patch for configure, thus one can't actually do

> > this. Â Can somone make a patch for configure to load Ruby dynamically?
>
> Attached.

That was quick! Thanks.

--
FIRST GUARD: Ah! Now ... we're not allowed to ...
SIR LAUNCELOT runs him through, grabs his spear and stabs the other
guard who collapses in a heap. Hiccoughs quietly.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD