Shared library in /usr/local/lib not found

Question

I don't get it. I usually install third party software into /usr/local so libraries are installed into /usr/local/lib and never had problems linking to these libraries. But now it suddenly no longer works:

$ gcc -lkaytils -o test test.c
/usr/bin/ld.gold.real: error: cannot find -lkaytils
/usr/bin/ld.gold.real: /tmp/ccXwCkYk.o: in function main:test.c(.text+0x15):
error: undefined reference to 'strCreate'
collect2: ld returned 1 exit status

When I add the parameter -L/usr/local/lib than it works but I never had to use this before. Header files in /usr/local/include are found without adding -I/usr/local/include.

I'm using Debian GNU/Linux 6 (Squeeze) which has an entry for /usr/local/lib in /etc/ld.so.conf.d/libc.conf by default and the ldconfig cache knows the library I'm trying to use:

k@vincent:~$ ldconfig -p | grep kaytils
        libkaytils.so.0 (libc6,x86-64) => /usr/local/lib/libkaytils.so.0
        libkaytils.so (libc6,x86-64) => /usr/local/lib/libkaytils.so

So what the heck is going on here? Where can I check which library paths are searched by gcc by default? Maybe something is wrong there.

Solution 1

gcc -print-search-dirs will tell you what path the compiler checks. /usr/local/lib is simply not among them, so your compile time linker (in this case the new gold ld from binutils) doesn't find the library while the dynamic one (ld-linux.so which reads the cache written by ldconfig) does. Presumably the builds you've done previously added -L/usr/local/lib as necessary in their makefiles (usually done by a ./configure script), or you installed binaries.

Solution 2

This is probably an issue of environment variables - you have something set that's including /usr/local/include but not /usr/local/lib

From the GCC mapage on environment variables

       CPATH specifies a list of directories to be searched as if speci‐
       fied with -I, but after any paths given with -I options on the com‐
       mand line.  This environment variable is used regardless of which
       language is being preprocessed.

and

       The value of LIBRARY_PATH is a colon-separated list of directories,
       much like PATH.  When configured as a native compiler, GCC tries
       the directories thus specified when searching for special linker
       files, if it can’t find them using GCC_EXEC_PREFIX.  Linking using
       GCC also uses these directories when searching for ordinary
       libraries for the -l option (but directories specified with -L come
       first).

try "printenv" to see what you have set

Comments

[kayahr]

No, I never used -L/usr/local/lib before and I tested on another linux system (Which is Debian 5 Lenny): It works there without -L even while -print-search-dirs does not list /usr/local/lib. So is this a new behaviour on newer Debian systems?

[kayahr]

printenv doesn't show anything with "PATH" in it (except PATH itself) or anything with GCC in it.

[kayahr]

Also tried on another Debian 6 box. Works, too. So it is only my own system which is affected by this.

[Yann Vernier]

If so, perhaps it is related to the gold linker. Check ld -version. The gold linker is in package binutils-gold and described as experimental. The normal linker is available as ld.bfd in recent versions.

[kayahr]

Found it. my system had binutils-gold package installed. Don't know why binutils searches /usr/local/lib and binutils-gold doesn't but for now I don't care. Removing the package fixed the problem. I accept your answer because you told me that I was using binutils-gold.

[Yann Vernier]

Sorry for the misleading guesses, then. Glad you found it.

[Ajith Antony]

I'm trying to solve the mystery myself. The older "BFD" linker includes /usr/local, as well as arch specific lib dirs. The "gold" linker only searches /lib and/usr/lib. Using binutils 2.23. Searched all the configure options with no luck as to how this mismatched happened.