cmake set the RUBY_LIBRARY to /usr/lib64/libruby.so but this library is no longer in use on Gentoo since we deprecated ruby 1.8 support. The reason for this is that code linked against an unversioned libruby.so would break when people switch implementations with "eselect ruby" A test case for this issue can be seen in sci-libs/shogun with USE=ruby. This fails because /usr/lib64/libruby.so is not found. The problem appears to lie in list of _RUBY_POSSIBLE_LIB_NAMES in Modules/FindRuby.cmake. This list starts with the unversioned options "ruby" and "ruby-static". Removing these locally fixed the problem since ruby${_RUBY_VERSION_SHORT_NODOT} later in the list matches our versioned libraries, e.g. /usr/lib64/libruby21.so. It may be better to move "ruby ruby-static" to the end of the list to cater for people who don't use a Gentoo-provided ruby versions. What is not clear to me is why the find_libary() later on accepts this version, rather than iterating over the options until it find an existing versioned variant that works. Perhaps there are other issues here that I did not find.
I wasn't able to reproduce. Could you please attach the failing build log and CMakeCache.txt?
Created attachment 434260 [details] build.log output
Created attachment 434262 [details] CMakeCache.txt
(In reply to Michael Palimaka (kensington) from comment #1) > I wasn't able to reproduce. Could you please attach the failing build log > and CMakeCache.txt? Done. Note that shogun only fails with USE=ruby since that is when the ruby part is built.
Is it possible /usr/lib64/libruby.so could be a dangling symlink?
(In reply to Michael Palimaka (kensington) from comment #5) > Is it possible /usr/lib64/libruby.so could be a dangling symlink? Yes, we used to have a /usr/lib64/libruby.so link as part of the eselect mechanism, but we stopped supporting that somewhere around ruby19. When I started looking at this issue I still had a dangling symlink around. I'm convinced that I removed that link while testing this issue, but I now see that it is still around. :-( Removing it makes the issue go away. @soap: can you also check that you have this link?
(In reply to Hans de Graaff from comment #6) > (In reply to Michael Palimaka (kensington) from comment #5) > > Is it possible /usr/lib64/libruby.so could be a dangling symlink? > > Yes, we used to have a /usr/lib64/libruby.so link as part of the eselect > mechanism, but we stopped supporting that somewhere around ruby19. When I > started looking at this issue I still had a dangling symlink around. > > I'm convinced that I removed that link while testing this issue, but I now > see that it is still around. :-( Removing it makes the issue go away. > > @soap: can you also check that you have this link? Removing kde then.
It looks like this link is only present on old (ca. 2008) systems that still had ruby 1.8 installed at some point. @ruby: a suggested fix would be to remove this link in the remove_symlinks() method of eselect-ruby. Please review attached patch: @@ -8,6 +8,7 @@ SVN_DATE="20151229" VERSION="20151229" bindir=/usr/bin +libdir=/usr/lib man1dir=/usr/share/man/man1 find_targets() { @@ -43,6 +44,13 @@ check_target() { remove_symlinks() { rm -f ${EROOT}${bindir}/{ruby,gem,irb,erb,ri,rdoc,testrb} && \ rm -f ${EROOT}${man1dir}/{ruby,irb,erb,ri}.1* + + # Remove unversioned legacy link set by ruby 1.8 and earlier + # see bug 582672 + local link="${EROOT}${libdir}/libruby.so" + if [[ -e ${link} ]]; then + rm -f ${link} + fi } create_man_links() {
I am running into this on newer systems. I had another on my build host from 2015. 12 Apr 4 2013 /usr/lib/libruby.so -> libruby18.so
(In reply to Hans de Graaff from comment #8) > @ruby: a suggested fix would be to remove this link in the remove_symlinks() > method of eselect-ruby. Please review attached patch: This patch is now available in eselect-ruby-20170723.
