[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121209025529.GF23126@port70.net>
Date: Sun, 9 Dec 2012 03:55:30 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: static linking and dlopen
* Rich Felker <dalias@...ifal.cx> [2012-12-08 17:52:37 -0500]:
> Presently, it does not work at all. At best, it loses all the
> advantages of static linking.
i think it can work
> With static linking, they would have to be loaded too. This means a
> static-linked program using dlopen would have to contain the entire
> dynamic linker logic. What's worse, it would also have to contain at
> least the entire libc, and if you were using static versions of any
> other library in the main program, and a loaded module referenced a
> dynamic version of the same library, you'd probably run into
> unpredictable crashing when the versions do not match exactly.
i think one could make a dso that has no dependency
(all dependencies are linked into it including libc),
and no pointers are passed (directly or indirectly)
to types which are not entirely part of the abi
between the dso and the main binary
(ie no FILE* or anything that might have different
internals on the two sides)
in that case dlopen() would work and even dlclose()
can be safe (as the programmer has control over the
entire code)
of course care should be taken and it might not be
very useful but one could implement loadable/unloadable
plugins with static linking
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.
