Bug 145166
| Summary: | Linker search paths dropped | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Josef Spillner <josef> |
| Component: | binutils | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | ivg231 |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-01-15 17:26:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
-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. *** Bug 145301 has been marked as a duplicate of this bug. *** 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. 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. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 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 /etc/ld.so.conf. 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): binutils-2.15.92.0.2-5 How reproducible: Always Steps to Reproduce: 1. create dummy C program, like: int main(){return 0;} 2. gcc -o test test.c -lmysqlclient_r 3. 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.