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
[EMAIL PROTECTED]
(Hmm. A little worrisome: http://www.junkbusters.com/cgi-bin/privacy
http://www.anonymizer.com/snoop.cgi )
