Project

General

Profile

Actions
Copy link

Bug #5188

closed

mkmf libpath order prevents use of custom libs

Added by jbl26 (Brian Lindauer) over 12 years ago. Updated over 12 years ago.

Status:
Third Party's Issue
Assignee:
luislavena (Luis Lavena)
Target version:
-
ruby -v:
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
Backport:
[ruby-core:38927]

Description

The sqlite3 gem has an option --with-sqlite3-lib, which lets you point it to a non-default location for the libsqlite3.so file. However, mkmf still tries to use the default system libsqlite3.so even when this option is specified. I've tracked the behavior down to what I think is a bug in mkmf.rb. The command it tries is

gcc -o conftest -I/usr/include/ruby/ruby-1.9.1/x86_64-linux -I/usr/include/ruby/ruby-1.9.1/ruby/backward -I/usr/include/ruby/ruby-1.9.1 -I. -I../../../../../../../../../include -I/usr/local/include -I/opt/local/include -I/sw/local/include -I/usr/include    -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -Wall -fno-strict-aliasing -fPIC conftest.c  -L. -L/usr/lib64 -L../../../../../../../../../lib -L/usr/local/lib -L/opt/local/lib -L/sw/local/lib -L/usr/lib -L.  -rdynamic -Wl,-export-dynamic     -lruby-static -lsqlite3  -lpthread -lrt -ldl -lcrypt -lm   -lc

Note that -L/usr/lib64 comes before the path I specified in --with-sqlite3-lib. If you have a matching library in /usr/lib64, it will always use that instead of the one you have pointed to.

This behavior is implemented in the link_command method of mkmf.rb:


def link_command(ldflags, opt="", libpath=$DEFLIBPATH|$LIBPATH)

I believe that, instead, this should be:


def link_command(ldflags, opt="", libpath=$LIBPATH|$DEFLIBPATH)
Actions
Copy link

Also available in: Atom PDF

Like0
Like0Like0Like0