Project

General

Profile

Actions

Bug #9760

open

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

Added by zanegray (Andrew DeMaria) almost 10 years ago. Updated over 1 year ago.

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

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)


Files

fix_default_libpath.diff (1.2 KB) fix_default_libpath.diff zanegray (Andrew DeMaria), 04/19/2014 10:12 PM
early-libdir.patch (1.24 KB) early-libdir.patch sorah (Sorah Fukumori), 08/27/2015 05:18 PM

Updated by nobu (Nobuyoshi Nakada) almost 10 years ago

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

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-core:62100]
    [ruby-trunk - Bug #9760]

Updated by knu (Akinori MUSHA) almost 10 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

Updated by knu (Akinori MUSHA) almost 10 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.

Updated by nagachika (Tomoyuki Chikanaga) almost 10 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?

Updated by knu (Akinori MUSHA) almost 10 years ago

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

Updated by knu (Akinori MUSHA) almost 10 years ago

  • Status changed from Closed to Open
Actions #8

Updated by sorah (Sorah Fukumori) over 8 years 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.

Actions #9

Updated by usa (Usaku NAKAMURA) over 8 years ago

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

Updated by sorah (Sorah Fukumori) over 8 years 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..

Actions #11

Updated by sorah (Sorah Fukumori) over 8 years ago

I'm positive to revert the change at r45640.

Actions #12

Updated by sorah (Sorah Fukumori) over 8 years 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]

Updated by sorah (Sorah Fukumori) over 8 years ago

  • Status changed from Closed to Open

Reverted r45640 at r52267. Hmm...

Updated by onur (Onur Küçük) almost 8 years ago

We have a system where

  • Ruby 1.8.7-p374 is installed system wide from distribution packages
  • There is a user setup with RVM to run Ruby 2.x running Redmine with Mysql

During Redmine bundle install, mysql2 gem is linking against the system Ruby, leading to issues like missing symbols etc. for the generated SO. The issue is happening with 2.2.3, 2.2.4 and 2.3.0 but it seems it is fixed in 2.3.1. I did not bisect but r52267 is probably what fixed it, thank you !

Updated by rhenium (Kazuki Yamaguchi) over 1 year ago

This is still an issue in the current master (e.g., https://github.com/ruby/openssl/issues/545).

If I understand correctly, mkmf.rb prepends libruby's path solely to prevent picking up a wrong libruby. Since the exact path of the correct libruby is known, I wonder if it's possible for mkmf.rb to just use it instead of the -L[...] -lruby combo to achieve the same thing.

BTW, Python 3.8 made an interesting change in https://bugs.python.org/issue21536: if the platform allows, extensions don't link to libpython (don't use -lpythonX.Y) and leave symbols unresolved until at runtime.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0