From owner-freebsd-hackers Fri Feb 1 20:24:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id D44AD37B419 for ; Fri, 1 Feb 2002 20:24:38 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g124OYM29180; Fri, 1 Feb 2002 20:24:34 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g124OXD03238; Fri, 1 Feb 2002 20:24:33 -0800 (PST) (envelope-from jdp) Date: Fri, 1 Feb 2002 20:24:33 -0800 (PST) Message-Id: <200202020424.g124OXD03238@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: bfischer@Techfak.Uni-Bielefeld.DE Subject: Re: problem w/ dlopen(); bug or feature? In-Reply-To: <20020201212028.GC2992@frolic.no-support.loc> References: <20020201201018.GB2992@frolic.no-support.loc> <20020201212028.GC2992@frolic.no-support.loc> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20020201212028.GC2992@frolic.no-support.loc>, Bjoern Fischer 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