Hi Om! > I still need to understand the role of /etc/ld.so.cache then. From > ldconfig man page: > > "ldconfig creates the necessary links and cache (for use by the run-time > linker, ld.so) to the most recent shared libraries found in the > directories specified on the command line, in the file /etc/ld.so.conf, > and in the trusted directories (/usr/lib and /lib). Exactly. :-) "For use by the run-time linker, ld.so". _Not_ for use by the linker that links object files together, ld. :-) ld.so is the dynamic linker, that loads all necessary shared libraries a program needs for its execution. It is called each time a program starts, to get everything into place. ld, on the other hand, doesn't look at ld.so.cache, and therefore must be called rather verbosely. > Thanks Jan. My bad with lproc. But there are other similar things: > > damani@damani-pc:~$ ldconfig -p | grep libGL.so.1 > libGL.so.1 (libc6) => /usr/X11R6/lib/libGL.so.1 > libGL.so.1 (libc6) => /usr/lib/libGL.so.1 > damani@damani-pc:~$ ld -lGL > ld: cannot find -lGL Yep, another one: ld only looks for "lib<name>.so" and "lib<name>.a"... not for "lib<name>.<a or so>.<any sequence of numbers>". Programs that already have been linked against GL will run properly (as ldconfig has determined the actual name of the library), but to link your own programs against GL, you'll have to create a link yourself /usr/lib/libGL.so -> /usr/lib/libGL.so.1 or give the library's full path to ld (without -l then). Note the trick libc is using: Under /lib and /lib/tls, there's only libc.so.6, so it should be impossible to use -lc... but wait, there's /usr/lib/libc.so, which is a ld script telling ld where to find the true libraries. ;-) Regards, Jan -- Jan C. Nordholz <jckn At gmx net>
Attachment:
signature.asc
Description: Digital signature