Hi,

current Ruby in stable is 2.4.1, which VIM is built with. Ruby package has Provides: libruby.so.2.4()(64bit) , so looking even for lower version will work, when newer Ruby will become stable. If not, please give me steps how you found out this problem and how to reproduce it. However, I build and release VIm in every situation possible, so possible rebuild will be in week at least. For now closing as NOTABUG, feel free to reopen with more info.

My Ruby-using plugins started erroring out that `has('ruby')` was false. Using strace, it was trying to read the `.2.4.1` file. Seen here by using `strings`:

% strings =vim | grep libruby
libruby.so.2.4.1

Meanwhile, I have 2.4.2 (which I see now is currently in `updates-testing`), so it'd be nice if a new build of Vim could follow it soon after it lands (or be added to the build override set if possible).

I've fixed it locally by adding a symlink from the 2.4.1 path to the 2.4.2 library. Maybe Vim should store and try to load from the SONAME path instead of the SOVERSION path?

Hi, could you please be more specific about plugins you are use? I remember that command-t had such strict version checks:

https://github.com/wincent/command-t/issues/192

You probably want to use packaged vim-command-t instead ...

That isn't the problem. I also have LustyBuffer and LustyJuggler which didn't work due to a lack of Ruby support. Without the symlink I put into place, `has('ruby')` returns 0 because it is looking for a file which doesn't exist now that Ruby has bumped its minor version number.

It appears to me that the issue is the modified libruby soname. That simply should never happened. It should always be libruby.so.2.4.0 for Ruby 2.4.x. I reported this Ruby upstream [1].


[1] https://bugs.ruby-lang.org/issues/14002

The SONAME for libruby.so.2.4.2 *is* libruby.so.2.4. The SOVERSION is a different thing (the SONAME path is a symlink to the SOVERSION implementation of that SONAME). Vim should open it by SONAME, not SOVERSION.

As Ben says SONAME of libruby.so.2.4.2 is libruby.so.2.4 so there is no problem as long as SONAME stays as libruby.so.2.4 during ruby 2.4.x series and there is correct symlink.

Looking at Vim's configure code, it is asking RbConfig::CONFIG['LIBRUBY_SO'] for this path. I only see the SONAME under LIBRUBY_ALIASES (requiring a split on whitespace and taking the first entry AFAICT). I don't know of its cross-platform behavior. I'll try making a PR to Vim upstream.

Perhaps the reason for this is:
* vim compilation stage sets '-DDYNAMIC_RUBY_DLL=\"libruby.so.2.4.2\"' :
  see
  https://kojipkgs.fedoraproject.org//packages/vim/8.0.1184/1.fc28/data/logs/x86_64/build.log
  and
  https://github.com/vim/vim/blob/master/src/configure.ac#L1907

* and it comes from $ ruby -rrbconfig -e "puts RbConfig::CONFIG['LIBRUBY_SO']" :
  https://github.com/vim/vim/blob/master/src/configure.ac#L1905

* then the result is embedded to the vim code directly:
  https://github.com/vim/vim/blob/master/src/option.c#L2336

Apparently vim should use -DDYNAMIC_RUBY_DLL=\"libruby.so.2.4\" instead, however modifying configure seems a bit troublesome.

See https://github.com/vim/vim/pull/2199.

I looked at the other dynamic language support required by Vim and Perl has a similar issue in that `perl-devel` is actually required in order to use it since it loads `libperl.so` instead of `libperl.so.5.24`.

IMO, VIM is using the right variable from RbConfig and the content of the variable is wrong. You both says that the "libruby.so.2.4" is the SONAME, so why is it listed among aliases and not as LIBRUBY_SO. I would hold any action prior Ruby upstream provides their input.

I agree with Vít, this code is in VIM since version 7.3.678 and worked since then. Issue is raised by Ruby, because upstream moved from not bumping soname patch number through one minor release to bumping it even for patch release. Let's wait for Ruby upstream answer. If fix wouldn't be possible in Ruby, then it should be fixed in VIm (and in every other application, which uses rbconfig::CONFIG['LIBRUBY_SO'] for getting SONAME).

Until we get answer from Ruby upstream, moving this to Ruby people.

The latest summary is wrong. The soname doesn't contain the patch (or tweak as upstream calls it) version at all.

libruby-2.4.2.so - 2 is major release number, 4 is minor release number, 2 is patch release number.

Vim upstream accepted patch with splitting output of rbconfig[LIBRUBY_ALIAS]. I still think this should be at least solved in Ruby by adding config key, which will give you exact value libruby.so.$(major).$(minor) or libruby.so (such value as SONAME should be accessible directly, not by splitting output).
Until Ruby upstream clarifies it, I'll leave this summary as it is and bugzilla will stay opened.

Ruby upstream will stay with bumping teeny number, because changes between releases disrupt strict ABI (that's how Ruby upstream interprets reason, why teeny bump is needed).
Changing this bugzilla summary to "rbconfig doesn't have config key for SONAME"

OK, the summary is finally correct :) .

As a sidenote, Ruby isn't breaking ABI by adding functions; we'd be on libc.so.10000 otherwise by now. Mucking with internals also isn't a problem; as long as behavior for code compiled against a previous version still works, the ABI is maintained.

Anyways, the Vim patch is required anyways since a Ruby version with the SONAME key doesn't exist yet.

Vim will be rebuilt in next testing update, I'll send build here.

The patch was applied in Ruby trunk and is going to be backported into Ruby 2.4, it would be better to patch Ruby, wouldn't be? And possibly revert the vim upstream patch ...

The Vim patch is still required for older versions of Ruby. Vim should be patched to use the new key and if it isn't available, fallback to the old logic.

I should mention - Vim will be rebuilt with current version of Ruby in buildroot - it means with ruby-2.4.1 in F26, because there isn't newer version in buildroot for F26.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.