Hi,

I would really appreciate if someone could help resolve a mystery regarding a binary i am reverse engineering and the way it is "miraculously" finding certain shared libraries.

Here is the deal : the binary (executable) I'll call program A comes in a tar package. When i untar the package in /opt I get top level directory I'll call 'A-install'. Within A-install are program A, some config files (which don't contain any paths to 'libs') and a subdirectory called 'libs' with a few shared libraries. Now I am assuming these shared lib are being DYNAMICALLY loaded (using dlopen() or whatever else can be used at runtime) because when I run ldd on program A I don't see the shared libraries from the 'libs' directory. Furthermore, I export LD_DEBUG=libs and with that set I see that program A finds and loads the shared libraries in the 'libs' subdir only in response to a specific runtime event, not upon startup.

I am using program A on a freshly installed suse linux 11 system. LD_LIBRARY_PATH is empty. So the big mystery in HOW is it finding these shared libraries?

I have the source to program A and I have also explored the use of the -rpath option during link time. I did an exhaustive search for any -rpath (thinking it might be set to something like -rpath=./libs ) setting in the linking. When I build program A I don't see -rpath option used in the build output.

Could anybody suggest any other possibilities as to how in the world program A is finding the 'libs' subdirectory and all the shared libriaries there.

I would be very grateful for any help.

Thanks much.

Hi -

You can use "ldd" to see WHICH shared libraries your executable requires, and exactly WHERE it's finding them.

If you want to understand "why", then Google is your friend. The short answer is:

1. Runtime "LD_LIBRARY_PATH"
2. build-time rpath
3. Standard "well known default paths" (/usr/lib, etc)

Two good links:
http://tldp.org/HOWTO/Program-Librar...libraries.html

http://linux.die.net/man/8/ld-linux

'Hope that helps

LDD is not useful for shared libraries loaded at RUNTIME. I explain this in my original post.

So far google has not been my friend either in this case. The things you mention I have already looked into. I have gone beyond that...this is why it is a mystery - for me anyway.

For those who might know where to look next here is one more detail I have not yet mentioned (I just discovered it). The shared libraries program A links with ( AT RUNTIME ) actally come with a prepackaged static lib that I DO NOT have sources to. Program A links with this static library. I am assuming that the code within this static library is what is loading the shared libraries (using DLOPEN()). Could that STATIC library have the path of the shared libraries encoded within???? Is that a reasonable hypothesis?? If so, how would I check the STATIC lib for any paths encoded into it??? Keep in mind I don't have the source to the STATIC lib.

Thanks in advance.

Hi -

*Every* shared library is loaded at "runtime" (no need for capitalization ).

And no, "ldd" won't show you libraries you didn't specify at link time (but might try to load dynamically with "dlopen()").

Yes, objects linked into to your executable from a shared library might themselves have some shared dependency. But those objects are no different from your executable (they're a *part* of your executable!), so you're in the same boat with "ldd" and friends.

Runtime variables include LD_LIBRARY_PATH (the biggie!), DT_RPATH ... and DT_RUNPATH:

http://linux.die.net/man/3/dlopen

You can also use the "strings" and/or "objdump" commands to see if there are any "magic paths" embedded in your executable that ldd isn't showing.

Q: Is there some real problem you're trying to resolve, or are you just curious?

Yes, a customer is suddenly experiencing problems with this 'program A' application where it is not able to find these shared libs.

I don't see this problem in my environment and most clients do not either. So now I am trying to understand the detailed mechanism by which the shared libs in question are normally found and loaded.

"*Every* shared library is loaded at "runtime" (no need for capitalization ).". Of-sourse, I was just emphasizing the distinction between linking at compile time and runtime and not being careful with semantics. Compile-time linking (not loading) to those shared libs would be easy (or easier) to resolve.

From most of what I have read about LD_LIBRARY_PATH it is not recommended for use with deployed software - it overrides system default search paths and all other paths (I think). In fact my first thought when they complained about this was that they set LD_LIBRARY_PATH or some similar variable that is screwing up linking to our shared libs. I'm still guessing that is the case, but I need to understand first how our 'program A' does in-fact find those shared libs, so I am not just guessing as to what their problem is.

Anyway, I am starting to get a reasonable picture about how these shared libs are loaded. I'm fairly certain it must be encoded into that STATIC lib (that is a black box to me) with which 'program A' links. I'd like to know for sure though.

So maybe your suggestions - 'strings' or objdump utilities - will resolve that for me. I have not thought to use those, so thanks for that.

Let me see what if anything those reveal.

Cool - it sounds like you're on the right track, and you have a solid gameplan. Good luck!

PS:
I would absolutely encourage you and your customers to make use of $LD_LIBRARY_PATH whenever applicable - there's nothing wrong with it. A common idiom is to modify the environment file (for example, /etc/profile globally, or ~/.bashrc per-user) like this:
This preserves any pre-defined path, and includes yours.

And if it resolves this particular problem - I would wholeheartedly endorse it as "the solution".

IMHO...