help: gcc/ld doesn't see libraries consistently
What might cause gcc not to be able to see some libraries that are
in the same directories as other libraries it can see?
For example, these references work:
$ gcc test.c -lc
$ gcc test.c -lcrypt
but these do not:
$ gcc test.c -lcfont
/usr/bin/ld: cannot find -lcfont
collect2: ld returned 1 exit status
$ gcc test.c -lconsole
/usr/bin/ld: cannot find -lconsole
collect2: ld returned 1 exit status
$ gcc test.c -lctutils
/usr/bin/ld: cannot find -lctutils
collect2: ld returned 1 exit status
$ gcc test.c -lcom_err
/usr/bin/ld: cannot find -lcom_err
collect2: ld returned 1 exit status
(The test program is simply "main() {}".)
I can't figure out what the difference is.
ldconfig lists all those libraries:
$ /sbin/ldconfig -p | grep "libc[^56]"
libctutils.so.0 (libc6) => /lib/libctutils.so.0
libcrypt.so.1 (libc6) => /lib/libcrypt.so.1
libcrypt.so (libc6) => /usr/lib/libcrypt.so
libconsole.so.0 (libc6) => /lib/libconsole.so.0
libcom_err.so.2 (libc6) => /lib/libcom_err.so.2
libcfont.so.0 (libc6) => /lib/libcfont.so.0
libc.so.6 (libc6) => /lib/libc.so.6
Directory /lib also contains them all:
bash-2.03$ ls -l /lib | grep "libc[^56]"
-rwxr-xr-x 1 root root 888596 Aug 14 18:11 libc-2.1.3.so
lrwxrwxrwx 1 root root 13 Aug 14 18:11 libc.so.6 -> libc-2.1.3.so
lrwxrwxrwx 1 root root 17 Aug 14 18:11 libcfont.so.0 -> libcfont.so.0.0.0
-rw-r--r-- 1 root root 12332 Aug 14 18:11 libcfont.so.0.0.0
lrwxrwxrwx 1 root root 17 Aug 14 18:11 libcom_err.so.2 -> libcom_err.so.2.0
-rw-r--r-- 1 root root 5244 Aug 14 18:11 libcom_err.so.2.0
lrwxrwxrwx 1 root root 19 Aug 14 18:11 libconsole.so.0 -> libconsole.so.0.0.0
-rw-r--r-- 1 root root 61224 Aug 14 18:11 libconsole.so.0.0.0
-rw-r--r-- 1 root root 20112 Aug 14 18:11 libcrypt-2.1.3.so
lrwxrwxrwx 1 root root 17 Aug 14 18:11 libcrypt.so.1 -> libcrypt-2.1.3.so
lrwxrwxrwx 1 root root 19 Aug 14 18:11 libctutils.so.0 -> libctutils.so.0.0.0
-rw-r--r-- 1 root root 18252 Aug 14 18:11 libctutils.so.0.0.0
The file command shows seemingly normal results:
bash-2.03$ file /lib/libc*
/lib/libc-2.1.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libc.so.6: symbolic link to libc-2.1.3.so
/lib/libcfont.so.0: symbolic link to libcfont.so.0.0.0
/lib/libcfont.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libcom_err.so.2: symbolic link to libcom_err.so.2.0
/lib/libcom_err.so.2.0: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libconsole.so.0: symbolic link to libconsole.so.0.0.0
/lib/libconsole.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libcrypt-2.1.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libcrypt.so.1: symbolic link to libcrypt-2.1.3.so
/lib/libctutils.so.0: symbolic link to libctutils.so.0.0.0
/lib/libctutils.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
Any ideas?
The only thing I notice is that in the /lib directory listing,
the non-symbolic-link versions of libc and libcrypt have version
numbers before the ".so" part:
... libc-2.1.3.so
... libc.so.6 -> libc-2.1.3.so
... libcrypt-2.1.3.so
... libcrypt.so.1 -> libcrypt-2.1.3.so
while for the other libraries the link name and the file name are
the same past the ".so" part:
... libctutils.so.0 -> libctutils.so.0.0.0
... libctutils.so.0.0.0
...
Could that have any relationship to the problem?
Is there any documentation on exactly how gcc or ld finds libraries?
The manual pages mention a default search mechanism, but never say
exactly what that is or how it works (e.g., in relation to symbolic
links or multiple files with the same prefix).
Thanks,
Daniel
--
Daniel Barclay
dsb@smart.net
(Hmm. A little worrisome: http://www.junkbusters.com/cgi-bin/privacy
http://www.anonymizer.com/snoop.cgi )
Reply to: