mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: static linking and dlopen
Date: Sun, 9 Dec 2012 03:39:00 +0100	[thread overview]
Message-ID: <20121209023900.GE23126@port70.net> (raw)
In-Reply-To: <CAKHv7pgVTBnUyUOq9d83LHw54XaOX1HAcS=4E117+sxc0Qe9Ew@mail.gmail.com>

* Paul Schutte <sjpschutte@gmail.com> [2012-12-09 02:04:43 +0200]:
> I was wondering about distributing all libraries as static libraries and
> then have the package manager link the application statically as the final
> step of the installation. This way the package manager can keep track
> of dependencies and re-link them if a library change.

note that binaries built by the user outside of the
package manager wont be relinked which may or may
not be what you want

static linking takes a lot of time and memory
(gold is better at this than gnu ld, but a libc
update would take some time either way)

you cannot easily collapse dependency chains:
eg. with x,y binaries, a,b,c objects and
 x->a->b->c
 y->b->c
dependency chains, the b->c linking is done twice
(so not much work can be shared between the linking
of various binaries and the linking of a huge binary
takes a lot of time even if an insignificant small
part changes)

other than dlopen the LD_PRELOAD and LD_LIBRARY_PATH
hacks would not work, nor system components that depend
on dynamic linking (vdso, proprietary libraries
(graphics drivers etc), nsswitch, pam)

i'm not saying your idea is bad, but it's non-trivial

> Another idea would be to just install a stub where the binary would be.
> First time you run this stub, it will link the binary and store it on the
> disk in some sort of cache. Then just do an exec of that binary. Second

i guess the stub would need setuid


  parent reply	other threads:[~2012-12-09  2:39 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 [this message]
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
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=20121209023900.GE23126@port70.net \
    --to=nsz@port70.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).