Program compiled with g++ -L option uses library from /usr/lib
 

I was unable to compile a program that used libicu42 on Ubuntu 11.04, because Ubuntu 11.04 has only libicu44 and does not have libicu42 installed.

So during compile time I used g++ prog.c -L mylib/ to compile the program. mylib had libicu42 (This library is a shared library and has the .so extension). The program compiled successfully, but when I tried to run it, it failed and complained that it did not find libicu42. So I had to manually install libicu42 in /usr/lib. Then the program worked.

'ldd prog' revealed that it looked for libicu42 in /usr/lib

What was the point of specifying the library path using -L, if the compiled program looked for the library in /usr/lib? It's almost like it was just to satisfy the compiler.

The -L option is used for libraries, that are not in your LD_LIBRARY_PATH.

And when you run your program, it will look for the libs in only the
LD_LIBRARY_PATH ( Like /lib:/usr/lib:usr/local/lib:/usr/lib/qt4/lib ).


The package libicu42_4.2.1-3_i386.deb or libicu42_4.2.1-3_amd64.deb
can usually be installed with no conflicts. The library names are
different from other libicu versions.
http://packages.ubuntu.com/maverick/libicu42

..

Thank you very much, it explains why the program was looking for files in /usr/lib. But what did g++ do with library path I specified, if the program was going to look for the library in the system?

When you do e.g. : g++ prog.c -L mylib/ -licudata

.. then the program will link to libicudata.so,
which is usually a link to libicudata.so.42.1 (or libicudata.so.42).


And afterwards running the executable, it will look for the "so name"
= libicudata.so.42 in the LD_LIBRARY_PATH.

A shared library holds information about "real name" (libicudata.so.42.1)
and "so name" (libicudata.so.42).
http://tldp.org/HOWTO/Program-Librar...libraries.html

..