From owner-freebsd-current Wed Nov 29 10: 9:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 06FA037B400; Wed, 29 Nov 2000 10:09:52 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id DE0FF1EA; Wed, 29 Nov 2000 10:09:50 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA12947; Wed, 29 Nov 2000 10:09:50 -0800 (PST) Message-ID: <3A25466D.1EDB4C0D@cup.hp.com> Date: Wed, 29 Nov 2000 10:09:49 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marc van Kempen Cc: bmah@FreeBSD.ORG, janb@cs.utep.edu, dmaddox@sc.rr.com, current@FreeBSD.ORG Subject: Re: Other Linux stuff... References: <200011290855.JAA09076@bowtie.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marc van Kempen wrote: > > > The only gain I see, if you can call it a gain, is that you can get > > non-trivial information out of a shared object from within scripts, but > > I don't know if this has been the reason. If you don't allow execution > > of shared objects, you have to use dlopen(3) and call some functions or > > query some variables. > > Would it be possible to write a small wrapper to load the shared library > and execute some entryfunction to get it started? I suppose that's what > the elf-loader under linux does. You mean something like MS Windows rundll? Yes, that should work in general. But may not in all cases. If the dynamic linker (ld-linux.so.2) checks the executable name to see if it has been started by the OS to perform dynamic linking for the binary or to see if it's executed itself for the dependency information (ie by ldd), then this may not work (I have to check if this is the case, but I don't think it's out of the question). > If so that would be a simple addition to the linux-lib port. For trivial cases, the simplest solution would be to just remove /compat/linux/usr/bin/ldd and have our native ldd do the work. If something depends on the switches, this won't work. I haven't come up with a solution I like. I also haven't paid much attention to it, because it doesn't seem a major problem. Suggestions are always welcome, of course. As a work-around, I can have linux_devtools remove ldd(1) so that it at least works for the trivial cases. I don't know why I haven't done this already :-) -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message