In article <[EMAIL PROTECTED]>, Bjoern Fischer <[EMAIL PROTECTED]> wrote: > On Fri, Feb 01, 2002 at 09:10:18PM +0100, Bjoern Fischer wrote: > > I have a problem with dlopen() on FreeBSD: When dlopen()ed > > shared objects dlopen() a shared object themselves, the DT_RPATH, > > that is hardcoded into the first dlopen()ed object is *not* > > searched. > > Ok, I've looked into /usr/src/libexec/rtld-elf/rtld.c:dlopen(). It > is obvious why dlopen-test does not work: The runtime linker only > searches in DT_RPATH of the main object obj_main. > > John, is it possible to find out in dlopen() which object in the > linked list has issued the dlopen() call? Then a fix would be easy.
Yes, it's possible to find out which shared object the dlopen call was made from. There's already a function obj_from_addr() in rtld.c which does that. But as far as I know, it is not standard behavior to search the RPATH of the object which issued the dlopen call. I try to follow the ELF specification and/or the behavior of Sun's dynamic linker, and I don't think either one specifies this sort of dynamic scoping. It's risky to get too creative in this area. Usually doing so breaks several random ports. > BTW, isn't the method of using a linked list for the objects a bit > limiting? Wouldn't be a tree structure better? If you're talking about efficiency, it doesn't matter very much. It's a rare program that loads more than, say, 20 shared libraries. If you're talking about functionality, the linked list isn't the only data structure. Each shared object is also inserted into a doubly-linked tree structure (actually a DAG) which represents the hierarchical relationships between the shared objects. That's done using the "dldags" and "dlmembers" members of the Obj_Entry structure. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
