mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: musl@lists.openwall.com
Subject: Re: static linking and dlopen
Date: Sun, 09 Dec 2012 14:43:31 -0600	[thread overview]
Message-ID: <1355085811.9353.4@driftwood> (raw)
In-Reply-To: <20121209100846.GB2925@openwall.com> (from croco@openwall.com on Sun Dec  9 04:08:46 2012)

On 12/09/2012 04:08:46 AM, croco@openwall.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

  parent reply	other threads:[~2012-12-09 20:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-08 18:09 Paul Schutte
2012-12-08 20:47 ` Szabolcs Nagy
2012-12-09 20:02   ` Rob Landley
2012-12-08 22:52 ` Rich Felker
2012-12-08 23:17   ` Charlie Kester
2012-12-08 23:23     ` Rich Felker
2012-12-09  0:04       ` Paul Schutte
2012-12-09  0:16         ` Rich Felker
2012-12-09 15:24           ` Paul Schutte
2012-12-09 17:54             ` Rich Felker
2012-12-09 19:07               ` Szabolcs Nagy
2012-12-09 19:24                 ` Rich Felker
2012-12-09  2:39         ` Szabolcs Nagy
2012-12-09  6:36     ` croco
2012-12-09  7:25       ` Isaac Dunham
2012-12-09  8:10         ` Charlie Kester
2012-12-09 10:08         ` croco
2012-12-09 11:46           ` Szabolcs Nagy
2012-12-09 15:11             ` Rich Felker
2012-12-09 20:43           ` Rob Landley [this message]
2012-12-08 23:29   ` Paul Schutte
2012-12-09  2:55   ` Szabolcs Nagy
2012-12-09  3:10     ` Rich Felker
2012-12-09  7:30     ` Isaac Dunham
2012-12-09 20:09   ` Rob Landley
2012-12-09 21:53     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1355085811.9353.4@driftwood \
    --to=rob@landley.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).