Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 564272 - >=dev-lang/ruby-2.1: mkmf sets LD_LIBRARY_PATH to random system paths
Summary: >=dev-lang/ruby-2.1: mkmf sets LD_LIBRARY_PATH to random system paths
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Ruby Team
URL:
Whiteboard:
Keywords: PATCH
: 563384 564756 567006 571230 (view as bug list)
Depends on:
Blocks: CVE-2015-7551
  Show dependency tree
 
Reported: 2015-10-27 17:00 UTC by Alexander Tsoy
Modified: 2017-07-23 07:33 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to fix src_install (ruby-2.2.3-ld-library.patch,574 bytes, patch)
2015-12-01 05:37 UTC, Aric Belsito
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Tsoy 2015-10-27 17:00:19 UTC
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
Comment 1 Alexander Tsoy 2015-10-28 12:59:02 UTC
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.
Comment 2 Tomáš Mózes 2015-11-03 19:28:20 UTC
*** Bug 564756 has been marked as a duplicate of this bug. ***
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-22 19:29:16 UTC
@Ruby, could we get some reply here, please?
Comment 4 Hans de Graaff gentoo-dev Security 2015-11-26 07:02:33 UTC
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.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-26 14:18:05 UTC
*** Bug 563384 has been marked as a duplicate of this bug. ***
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-26 14:24:41 UTC
I'd just apply it and see what happens. If something breaks, we can try to get some other solution.
Comment 7 Hans de Graaff gentoo-dev Security 2015-11-29 10:07:03 UTC
(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.
Comment 8 Hans de Graaff gentoo-dev Security 2015-11-29 10:58:38 UTC
This should now be fixed with ruby-2.1.7-r1 and ruby-2.2.3-r2
Comment 9 Hans de Graaff gentoo-dev Security 2015-11-29 11:00:12 UTC
*** Bug 567006 has been marked as a duplicate of this bug. ***
Comment 10 Aric Belsito 2015-12-01 05:37:35 UTC
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.
Comment 11 Hans de Graaff gentoo-dev Security 2016-05-16 14:45:04 UTC
(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.
Comment 12 Anthony Basile gentoo-dev 2016-05-31 15:44:55 UTC
(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"
Comment 13 Anthony Basile gentoo-dev 2016-06-04 15:44:06 UTC
@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.
Comment 14 Hans de Graaff gentoo-dev Security 2016-06-05 07:20:34 UTC
(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.
Comment 15 Hans de Graaff gentoo-dev Security 2016-06-06 06:01:41 UTC
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.
Comment 16 Hans de Graaff gentoo-dev Security 2017-07-23 07:33:16 UTC
*** Bug 571230 has been marked as a duplicate of this bug. ***