[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121209063658.GA2925@openwall.com>
Date: Sun, 9 Dec 2012 10:36:58 +0400
From: croco@...nwall.com
To: musl@...ts.openwall.com
Subject: Re: static linking and dlopen
Hi folks,
On Sat, Dec 08, 2012 at 03:17:09PM -0800, Charlie Kester wrote:
> I wonder if most of what people want to do with dlopen couldn't be done
> just as well (or better) with good old fork() and exec(), along with
> some suitable interprocess communication.
The thing I recalled right off, is that, e.g., interpreters of Tcl are able
to load C-written functions to extend the functionality of the interpreter
(e.g. with a domain-specific set of functions), and this is done with
dlopen. I think Tcl is not the only interpreter doing so. I even used the
same technique in one of my works (it was an interpreter of (small subset
of) Lisp, extendable in the same way). Well, may be this (in theory) can
be done with fork/exec, with some protocol on the pipes, etc., but as for
me, I would never use such a solution, preferring to keep the interpreter
non-extendable: having library functions' implementations in an external
process conflicts with my sense of aesthetics :-)
IMHO, for some (monstrous) programs such as browsers, or Gimp, or whatever
alike, having all the dynamic linking logic inside is not a catastrophe,
because the catastrophe is their size as such. For interpreters, the
catastrophe is the fact of interpreted execution, and dlopen will add
next to nothing to it.
Anyway, for a lot of existing programs, the absense of dlopen will mean a
necessity for heavy rewritings in order to compile them with musl - perhaps
too heavy to be done at all.
P.S. thank you for the great work you do!
--
Cheers,
Croco
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
