Bug 145166 - Linker search paths dropped
Linker search paths dropped
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: 145301 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-01-14 16:32 EST by Josef Spillner
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-15 12:26:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josef Spillner 2005-01-14 16:32:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:
When compiling a program and linking against a library
(mysqlclient_r), which is not in /usr/lib, the linker fails.
This wouldn't be a tragedy in itself since -L/usr/lib/mysql could be
added, however this shouldn't be necessary since this path is in
Even though the linker knows this, it doesn't act accordingly.
A lot of configure scripts fail due to this misbehaviour.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
create dummy C program, like: int main(){return 0;}
gcc -o test test.c -lmysqlclient_r
gcc -o test test.c -L/usr/lib/mysql -lmysqlclient_r

Actual Results:  Step 2 failed since libmysqlclient_r.a cannot be found.

Expected Results:  Normally, steps 2 and 3 should give the same
result, since /usr/lib/mysql is included in /etc/ld.so.conf.

Additional info:

I think this could be due to selinux being enabled.
At least in the mail sent to root about invalid file contexts,
/etc/ld.so.cache is included.
Also the strace'd gcc call includes /usr/lib/mysql for some time until
the selinux context switch occurs.
Comment 1 Jakub Jelinek 2005-01-15 12:26:24 EST
-L/usr/lib/mysql is necessary.
/etc/ld.so.conf (and /etc/ld.so.conf.d/*.conf) is used for searching shared
libraries (usually lib*.so.*), but that's not what linker is using when you
specify -lmysqlclient on the command line.
With -lmysqlclient linker is looking for lib*.so files (which are usually
symlinks to lib*.so.* files, but not necessarily so and don't need to be in the
same directory either).
So you need to tell the linker that you want to search there and in which order
to search the -L directories.

On the other side, when you are linking against some shared library that has
say libmysqlclient.so.10 as its dependency (DT_NEEDED dynamic tag), linker will
use also /etc/ld.so.conf* to locate that shared library.
This is all documented in the ld documentation, see info ld.
Comment 2 Jakub Jelinek 2005-01-17 01:26:10 EST
*** Bug 145301 has been marked as a duplicate of this bug. ***
Comment 3 Ivan Gyurdiev 2005-01-17 01:50:28 EST
Why is that so? What's the logic of this? 
The .so links are usually in the same folder as the actual libs,
so why can't ld just search those folders like ldconfig does?

Also..the man page talks about searching ld.so.conf under
the -rpath-link option.
Comment 4 Jakub Jelinek 2005-01-17 01:55:36 EST
Usually is not enough, it would need to be always if ld was to change behaviour.
Anyway, we certainly aren't going to diverge from upstream for this documented
behaviour, so it is pointless to argue about this here.

Note You need to log in before you can comment on or make changes to this bug.