Project

General

Profile

Bug #9760

mkmf does not allow for linking against custom libraries when a system library is present

Added by Andrew DeMaria about 2 years ago. Updated 6 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
ruby -v:
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]
[ruby-core:62100]

Description

Hi,

Hopefully the title is not confusing, but the short story is that mkmf outputs a makefile that first searches the default lib path before searching any user provided lib paths. This is not an issue until one tries to link against an included library whose version is different than a preexisting system library.

The issue cropped up while trying to install the rugged gem (libgit2 wrapper) and a full dialog on the issue can be found on github https://github.com/libgit2/rugged/issues/351.

I was able to fix the issue with the attached patch (https://github.com/muff1nman/ruby/commit/a0c8bc32cfc11e61c5b9703bff243934c6509210)

fix_default_libpath.diff Magnifier (1.2 KB) Andrew DeMaria, 04/19/2014 10:12 PM

early-libdir.patch Magnifier (1.24 KB) sorah Shota Fukumori, 08/27/2015 05:18 PM

Associated revisions

Revision 45640
Added by Nobuyoshi Nakada about 2 years ago

mkmf.rb: prefer $LIBPATH than $DEFLIBPATH

  • lib/mkmf.rb (link_command, libpathflag, create_makefile): prefer user specified $LIBPATH than $DEFLIBPATH. [ruby-trunk - Bug #9760]

Revision 45640
Added by Nobuyoshi Nakada about 2 years ago

mkmf.rb: prefer $LIBPATH than $DEFLIBPATH

  • lib/mkmf.rb (link_command, libpathflag, create_makefile): prefer user specified $LIBPATH than $DEFLIBPATH. [ruby-trunk - Bug #9760]

Revision 45640
Added by Nobuyoshi Nakada about 2 years ago

mkmf.rb: prefer $LIBPATH than $DEFLIBPATH

  • lib/mkmf.rb (link_command, libpathflag, create_makefile): prefer user specified $LIBPATH than $DEFLIBPATH. [ruby-trunk - Bug #9760]

Revision 52267
Added by sorah Shota Fukumori 6 months ago

  • lib/mkmf.rb: Revert r45640 because it may lead to link with different libruby. [Bug #9760]

Revision 52267
Added by sorah Shota Fukumori 6 months ago

  • lib/mkmf.rb: Revert r45640 because it may lead to link with different libruby. [Bug #9760]

History

#1 [ruby-core:62101] Updated by Nobuyoshi Nakada about 2 years ago

  • % Done changed from 0 to 100
  • Status changed from Open to Closed

Applied in changeset r45640.


mkmf.rb: prefer $LIBPATH than $DEFLIBPATH

  • lib/mkmf.rb (link_command, libpathflag, create_makefile): prefer user specified $LIBPATH than $DEFLIBPATH. [ruby-trunk - Bug #9760]

#2 [ruby-core:62444] Updated by Akinori MUSHA almost 2 years ago

In the meantime, third parties can work around this problem by a monkey patch like this:

https://github.com/sparklemotion/nokogiri/commit/c98745d9098487c51685a732f1c5a21d8d07cdad

#3 [ruby-core:62668] Updated by Akinori MUSHA almost 2 years ago

The monkey patch I mentioned above was backed out due to a serious problem found, that is, if an instance of libruby.so (of the same soname as the running ruby) is found in a user-given path that is different from the one for the running ruby used for build, it will be picked by the linker and the resulted extension will cause a SEGV in run time.

So, it turned out DEFLIBPATH took precedence over LIBPATH for a good reason and I'm afraid it should not have been simply changed this way.

#4 [ruby-core:63135] Updated by Tomoyuki Chikanaga almost 2 years ago

  • Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN to 2.0.0: UNKNOWN, 2.1: REQUIRED

Does this issue exist in 2.0.0 too?

#5 [ruby-core:63137] Updated by Akinori MUSHA almost 2 years ago

Please do not backport this yet; I'm suggesting backing out the commit made in trunk for the reason I gave above.

#6 [ruby-core:63138] Updated by Akinori MUSHA almost 2 years ago

  • Status changed from Closed to Open

#8 Updated by sorah Shota Fukumori 8 months ago

attached diff (early-libdir.patch) works well for my case... but I can't determine this is correct fix. If it's okay I'll commit into trunk.

#9 Updated by Usaku NAKAMURA 8 months ago

  • Backport changed from 2.0.0: UNKNOWN, 2.1: REQUIRED to 2.0.0: UNKNOWN, 2.1: REQUIRED, 2.2: REQUIRED

#10 Updated by sorah Shota Fukumori 8 months ago

Assume /usr/lib has librubyA and libfooB, and /home/someone/local/lib has libfooA. I think early-libdir.patch makes mkmf.rb can't link to libfooA never..

#11 Updated by sorah Shota Fukumori 8 months ago

I'm positive to revert the change at r45640.

#12 Updated by sorah Shota Fukumori 6 months ago

  • Status changed from Open to Closed

Applied in changeset r52267.


  • lib/mkmf.rb: Revert r45640 because it may lead to link with different libruby. [Bug #9760]

#13 [ruby-core:71179] Updated by sorah Shota Fukumori 6 months ago

  • Status changed from Closed to Open

Reverted r45640 at r52267. Hmm...

Also available in: Atom PDF