Why would a runtime undefined symbol be fixed by adding /usr/lib to ld.so.conf?

I've got a case in linux where gcc and ld build things cleanly, but at runtime I get an undefined symbol (fo开发者_如何学JAVAr something in libxerces-c.so.28), reported by one of my own shared libraries, when running my program.

First assumption was cache was broken, xerces recently installed, or something similar, so I ran ldconfig. Didn't fix it. But adding /usr/lib to ld.so.conf and then running ldconfig did fix it.

My understanding is /lib, /usr/lib, and perhaps one or two other spots are always searched by the run-time dynamic linker.

??

(The only thing out of the ordinary is this is a java program using jni to access application shared-libraries. Then again, if it were anything rational I should have seen this error any time in the past N years of this application.)

In this particular case, the library was in /usr/lib, but also in with another project (and the linker was finding that one first). And it must have been a bad/incomplete one, since it was obviously missing a symbol.

I figured this out by running my program as

LD_DEBUG=libs ./a.out

That let me watch the linker dig through the different search paths, and I saw it grab the wrong one.

Oh - and explicitly adding /usr/lib to the ld configuration? That just put /usr/lib earlier in the search path than it normally would have been, and (luck?) made ld find the good library before the bad one.