Date: Fri, 1 Feb 2002 20:24:33 -0800 (PST) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: bfischer@Techfak.Uni-Bielefeld.DE Subject: Re: problem w/ dlopen(); bug or feature? Message-ID: <200202020424.g124OXD03238@vashon.polstra.com> In-Reply-To: <20020201212028.GC2992@frolic.no-support.loc> References: <20020201201018.GB2992@frolic.no-support.loc> <20020201212028.GC2992@frolic.no-support.loc>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20020201212028.GC2992@frolic.no-support.loc>, Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202020424.g124OXD03238>