From: knu@...
Date: 2014-05-19T06:01:09+00:00
Subject: [ruby-core:62668] [ruby-trunk - Bug #9760] mkmf does not allow for linking against custom libraries when a system library is present

Issue #9760 has been updated by Akinori MUSHA.


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.

----------------------------------------
Bug #9760: mkmf does not allow for linking against custom libraries when a system library is present
https://bugs.ruby-lang.org/issues/9760#change-46803

* Author: Andrew DeMaria
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
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)


-- 
https://bugs.ruby-lang.org/