On Mon, Jul 4, 2016 at 12:44 AM, Janne Johansson <[email protected]> wrote: > OpenBSD will not make B load C just by A loading B, so the program A needs > to ask for both B and C while being linked in order to work.
It depends on what "depends" means. :-) > 2016-07-03 16:49 GMT+02:00 Tinker <[email protected]>: >> Am debugging something and am not quite clear about details. >> >> My executable A loads library B dynamically, and B depends on library C. What do you (the original poster) mean by "depends on"? If you just mean "needs, requires the resources of" then no, how would the OS know? If you mean "has listed as a dependency via DT_NEEDED entries" then yes, OpenBSD supports dependencies that way. >> C is located in /usr/local/lib/ . >> >> When I run A with "LD_PRELOAD=/usr/local/lib/C.so", A works. >> >> When I run A with "LD_LIBRARY_PATH=/usr/local/lib/", A does not work >> (loading/initializing B fails somehow). "somehow"? Come on, Tinker, you're not new to this! Not giving the exact error messages just wastes peoples time by making them guess! It *sounds* like C wasn't specified as a dependency of whatever (A? B?) actually requires it, which would have been a error in how the depending object was built. Or maybe not, since we have no information at all about these objects or the failure. >> And when I just run A, A does not work (same reason). >> >> Any thought about what I missed? >> >> Also, just for clarity, is /usr/local/lib/ in the default search path for >> library files? At link time, when searching for files to resolve a -l option to gcc or ld, no, /usr/local/lib is not in the default search path. At run time, when searching for a shared-object for dlopen() or as a DT_NEEDED dependency of the executable or another shared-object, yes, /usr/local/lib is in the default search path. Philip Guenther
