[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1355085811.9353.4@driftwood>
Date: Sun, 09 Dec 2012 14:43:31 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: static linking and dlopen
On 12/09/2012 04:08:46 AM, croco@...nwall.com wrote:
> On Sat, Dec 08, 2012 at 11:25:29PM -0800, Isaac Dunham wrote:
> > I think there's a misunderstanding here:
> >
> > musl includes a dlopen function.
> > When a binary is statically linked, it is a stub.
> > When a binary is dynamically linked, it loads the shared library
> requested.
>
> Oh, well, I didn't catch the situation; if this is the case, the
> things are
> definitely better. However, to my mind, static linkage is good for
> creating portable binaries (besides all the other advantages),
And musl has good support for static linking. Musl has good support for
dynamic linking. Mixing the two is a bad idea at the design level,
which posix does not guarantee to work.
> and I can
> easily imagine a situation in which I dislike the idea of a
> dynamically-linked main binary (e.g. I ship some unusual software to
> endusers, and they have different Linux distros but are not going to
> build
> the soft from sources - yes, there are such Linux users who panic
> when they
> hear the word "compiler" - and I've got no hope someone else will
> package
> my soft for different distros, because it is too unusual, so either I
> spend
> my time installing 20+ different versions of various distros and
> prepare
> packages for them all, or I opt for -static).
Yay static linking.
> So, I'd like to have all the
> libs inside the binary of, e.g., my interpreter (actually, this can
> be a
> program which does its job being controlled by embedded
> interpreter). But,
> at the same time, it is very possible I need these loadable modules,
> which
> extend the functionality of the interpreter.
If you need dynamic linking, then you need dynamic linking.
> Surely it is not a
> catastrophe, as I can link all libs but musl statically, and provide
> libmusl.so along with the binary, also having a script which sets
> LD_LIBRARY_PATH and then runs the binary; but it is a bit, errr...
> /strange/ :)
You want a statically, dynamically linked program. Presumably combining
PIC and non-PIC code.
Good luck.
> Actually, when it comes to -static, the linker only picks the modules
> that
> contain unresolved symbols, so it should (am I right?) be easy to
> break the
> things down to modules so that all the dynamic linkage mechanics is
> linked
> into the binary only in case it calls dlopen. And, okay, to mention
> in the
> man 3 dlopen that using it from within a statically-linked binary will
> increase the size of the binary by another megabyte, and that the .so
> to be
> loaded must itself use statically-linked version of libraries so that
> some
> functions will be loaded to the code segment twice. Such practice
> should
> be discouraged but I don't think it should be made impossible at all.
>
> I realize, however, that it is possible I simply miss something.
You're confusing "possible" with "a good idea". Many truly horrible
ideas aren't actually impossible, as Windows extensively demonstrates.
Possibly what you want is large chunks of the musl dynamic loader
factored out so you can easily suck them into your program and keep the
pieces when it breaks.
Rob
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.
