mkmf from >=ruby-2.1 sets LD_LIBRARY_PATH to random system paths. This causes build failures for several dev-ruby/* packages. See bug #562060 for more info. Steps to reproduce: - Install sys-libs/binutils-libs and rebuild sys-devel/binutils with USE=multitarget. Versions of these packages must match. - Try to install (for example) dev-ruby/racc or dev-ruby/dep_selector with >=ruby21 in RUBY_TARGETS. This bug can be fixed by the following patch: https://github.com/chef/omnibus-software/blob/master/config/patches/ruby/ruby-2_1_3-no-mkmf.patch
Alternative solution is to set LIBPATHENV="" in ebuild (LIBPATHENV="" econf ...). But I have no clue if this config variable is really needed by ruby at runtime or not.
*** Bug 564756 has been marked as a duplicate of this bug. ***
@Ruby, could we get some reply here, please?
I won't be able to look at this in detail until the weekend. I don't think the chef patch would make a good patch since their aim is to get a working ruby-for-chef, and our goal is to get a working ruby in general. While the chef patch points at things we can do, I don't think we should just apply this.
*** Bug 563384 has been marked as a duplicate of this bug. ***
I'd just apply it and see what happens. If something breaks, we can try to get some other solution.
(In reply to Alexander Tsoy from comment #1) > Alternative solution is to set LIBPATHENV="" in ebuild (LIBPATHENV="" econf > ...). But I have no clue if this config variable is really needed by ruby at > runtime or not. I think this is the right approach. This code was introduced as an extra measure to handle --disable-rpath. As far as I know we can rely on the Gentoo environment to be sane and not require embedded rpath in extension *and* not need LD_LIBRARY_PATH in this case. I'm currently testing this approach.
This should now be fixed with ruby-2.1.7-r1 and ruby-2.2.3-r2
*** Bug 567006 has been marked as a duplicate of this bug. ***
Created attachment 418268 [details, diff] Patch to fix src_install I recently tried to install ruby-2.2.3-r2, and it failed to build because ruby22 can no longer find libruby22.so.2.2 which is in the source directory. Prior to fixing this bug, I had no issues installing ruby. Adding the source directory to the LD_LIBRARY_PATH during src_install() fixed it for me.
(In reply to Aric Belsito from comment #10) > Created attachment 418268 [details, diff] [details, diff] > Patch to fix src_install > > I recently tried to install ruby-2.2.3-r2, and it failed to build because > ruby22 can no longer find libruby22.so.2.2 which is in the source directory. > Prior to fixing this bug, I had no issues installing ruby. > > Adding the source directory to the LD_LIBRARY_PATH during src_install() > fixed it for me. Aric, is this still an issue for you? We have not been able to reproduce this and there have been no further bug reports, so I'm wondering is this is something specific to your system.
(In reply to Hans de Graaff from comment #11) > (In reply to Aric Belsito from comment #10) > > Created attachment 418268 [details, diff] [details, diff] [details, diff] > > Patch to fix src_install > > > > I recently tried to install ruby-2.2.3-r2, and it failed to build because > > ruby22 can no longer find libruby22.so.2.2 which is in the source directory. > > Prior to fixing this bug, I had no issues installing ruby. > > > > Adding the source directory to the LD_LIBRARY_PATH during src_install() > > fixed it for me. > > Aric, is this still an issue for you? We have not been able to reproduce > this and there have been no further bug reports, so I'm wondering is this is > something specific to your system. this is also failing for me and can confirm that that following fixed it. notice all i did was prepend the source directory using a . to the LD_LIBRARY_PATH. i don't get why it works without this since the build needs to find libruby21.so (in my case, or 22 above). its probably working for you since you already have libruby21.so in your LD_LIBRARY_PATH which leaks in from the environment. but building from within a chroot starting from a fresh stage3 and you get breakage every time. diff --git a/dev-lang/ruby/ruby-2.1.9.ebuild b/dev-lang/ruby/ruby-2.1.9.ebuild index 5a82290..0b4dc0e 100644 --- a/dev-lang/ruby/ruby-2.1.9.ebuild +++ b/dev-lang/ruby/ruby-2.1.9.ebuild @@ -181,7 +181,7 @@ src_install() { local MINIRUBY=$(echo -e 'include Makefile\ngetminiruby:\n\t@echo $(MINIRUBY)'|make -f - getminiruby) - LD_LIBRARY_PATH="${D}/usr/$(get_libdir)${LD_LIBRARY_PATH+:}${LD_LIBRARY_PATH}" + LD_LIBRARY_PATH=".:${D}/usr/$(get_libdir)${LD_LIBRARY_PATH+:}${LD_LIBRARY_PATH}" RUBYLIB="${S}:${D}/usr/$(get_libdir)/ruby/${RUBYVERSION}" for d in $(find "${S}/ext" -type d) ; do RUBYLIB="${RUBYLIB}:$d"
@ruby this is causing bug #571230, bug #584894, and its causing some of my releng stuff to fail. I'd like to apply the fix to ruby-2.0.0_p647-r1.ebuild ruby-2.0.0_p648.ebuild ruby-2.1.10.ebuild ruby-2.1.7.ebuild ruby-2.1.9.ebuild ruby-2.2.5.ebuild ruby-2.3.0.ebuild ruby-2.3.1.ebuild which are currently broken.
(In reply to Anthony Basile from comment #12) > its probably working > for you since you already have libruby21.so in your LD_LIBRARY_PATH which > leaks in from the environment. but building from within a chroot starting > from a fresh stage3 and you get breakage every time. I've tried to reproduce this in various ways, starting from a fresh stage3, but I cannot reproduce this issue, either with ruby 2.1.9 or with a ~amd64/RUBY_TARGETS=ruby22 stage 3 for ruby 2.2.5. > ruby-2.0.0_p647-r1.ebuild > ruby-2.0.0_p648.ebuild > ruby-2.1.7.ebuild If these versions are also broken for you then my suggestion would be to open a new bug and try to find out the root cause ther, since these ebuilds have not been changed for the LD_LIBARY_PATH issue of this bug.
After some more debugging and discussion with blueness on IRC the reported problems are now clear and appear to be limited to use of uclibc and musl. With a blank LIBPATHENV the ruby build tools fall back to using LD_PRELOAD to load libruby.so during the build process. With uclibc, preloading is now optional and not enabled at least in the vanilla stage3 that we produce. This causes the build to fail since there are no options left to find libruby.so. The patch proposed by blueness fixes this by injecting the right location in the environment via LD_LIBRARY_PATH. I have now applied this patch to affected ebuilds, using ${S} instead of . to be more explicit and to match handling of RUBYLIB below it.
*** Bug 571230 has been marked as a duplicate of this bug. ***