disciple wrote:The problem is, we dropped the ball so long ago by not integrating the dev environment with the packaging environment, that now its really too late for a small team to go back and pick up the ball and "do it right" ... but we can at least do it better
I'm struggling to follow you here - have you come straight from the package management thread by any chance?
Who is the "we" you refer to? Puppy packagers? Developers of Linux software in general? Distro builders in general?
not just Linux, pretty much all *nixes. Have you ever watched what a ./configure script does or gone through one? OMG, what a disaster, but I find it hilarious when I download a 1000 byte program with a 100kb config script - Rob Landley says it best
http://landley.net/notes-2011.html#28-08-2011
*BSD has bsdbuild and others which do essentially the same thing
my point with integrating dev and packaging was that all of the garbage that the configure script does, could already be done by a properly setup package management system
for example (not well thought out, but just a "for instance")
if a library (libmyclib) provides snprintf it could add the following to the "<systemconfig_file>"
#define HAS_SNPRINTF -lmyclib
which would not only tell the system that we have snprintf, but how to link it
... the only plausible way to even attempt this (and get it into mainstream) is to try and shim it into the autotools caching mechanism to make it think it has already verified everything
.....sorry to get off topic, but getting back to shared vs. static
shared libs are vulnerable to this
LD_PRELOAD=/tmp/vicious_attacklib.so <binary>
if a shared lib has a vulnerability ALL of the programs linked against it also do (with a static link, some may have been linked against non-vulnerable versions or the vulnerable code may not even be linked in if it isn't used)
and it is FUD that static binaries are slower (in fact they are ~100-4000% faster)
http://sta.li/faq
* fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. I consider this alone (together with the next one) to be the killer arguments.
breakages only have to be applied in 1 place too
If you maintain your source tree its pretty easy to figure out using simple tools (find and grep).
and verify changes/lack of changes using edelta or xdelta
* Security measures like load address randomization cannot be used. With statically linked applications, only the stack and heap address can be randomized. All text has a fixed address in all invocations. With dynamically linked applications, the kernel has the ability to load all DSOs at arbitrary addresses, independent from each other. In case the application is built as a position independent executable (PIE) even this code can be loaded at random addresses. Fixed addresses (or even only fixed offsets) are the dreams of attackers. And no, it is not possible in general to generate PIEs with static linking. On IA-32 it is possible to use code compiled without -fpic and -fpie in PIEs (although with a cost) but this is not true for other architectures, including x86-64.
yes, because they aren't nearly as vulnerable to the primary vectors for those exploits such as LD_* attacks and ldd escalations (people put locks on doors, not walls)
you _can_ "statically" link a pie, just compile your "static" lib(s) with -fpic (you will get the dirty pages and other pic overhead but at least the unused code will be removed)
* more efficient use of physical memory. All processes share the same physical pages for the code in the DSOs. With prelinking startup times for dynamically linked code is as good as that of statically linked code.
no, they share _some_ pages (only read only), add quite a few extra dirty pages and if you prelink then the load times skyrocket once you change a single shared lib - dont ever do it, it will suck almost immediately
I have tested this with a plethora of compiler/linker optimizations, hacks and tricks and the closest I could get to the speed of its static binary counterpart's startup was still only half as fast
* all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking to load the appropriate external code. We have very limited support for doing this in statically linked code. But it requires that the dynamically loaded modules available at runtime must come from the same glibc version as the code linked into the application. And it is completely unsupported to dynamically load DSOs this way which are not part of glibc. Shipping all the dependencies goes completely against the advantage of static linking people site: that shipping one binary is enough to make it work everywhere.
another wontfix glibc bug
* Related, trivial NSS modules can be used from statically linked apps directly. If they require extensive dependencies (like the LDAP NSS module, not part of glibc proper) this will likely not work. And since the selection of the NSS modules is up the the person deploying the code (not the developer), it is not possible to make the assumption that these kind of modules are not used.
yet another wontfix glibc bug
* no accidental violation of the (L)GPL. Should a program which is statically linked be given to a third party, it is necessary to provide the possibility to regenerate the program code.
seriously - you don't think it is possible to accidentally violate lgpl ... if you can't remember what library version a program is linked against (because you didn't track it), what magic makes you remember patching it to build your code
if you are statically linking there is no doubt whether or not you need to include the static libs of lgpl libs
* tools and hacks like ltrace, LD_PRELOAD, LD_PROFILE, LD_AUDIT don't work. These can be effective debugging and profiling, especially for remote debugging where the user cannot be trusted with doing complex debugging work.
exactly, but there are others that do that _aren't_ a giant gaping security hole... tools that aren't designed specifically for shared libraries (strace for instance) do work ... thats like saying hammers don't make very good screwdrivers