|
Message-ID: <20121209023900.GE23126@port70.net> Date: Sun, 9 Dec 2012 03:39:00 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: static linking and dlopen * Paul Schutte <sjpschutte@...il.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
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.