4 ms·

statically linking to properly(!) made libraries will only maybe increase storage space it will decrease memory usage (as most loaders load the whole library, e

statically linking to properly(!) made libraries will only maybe increase storage space it will decrease memory usage (as most loaders load the whole library, even when just one function is used) Most OS linkers already do efficient loading of only the relevant portions of a shared library since they typically mmap the library file. In aggregate, static linking the same dependency for multiple programs will increase memory usage as well despite your assertions to the contrary since the pages will not generally be shared (yes, I'm aware some OS have page dedup or compression, etc., but I'm talking about the general case here). more things to upgrade, yes more bandwidth, yes (not much if one uses binary diffs) A binary diff of 100 programs all linking to the same library will still be larger than the diffs for a single library. In addition, updating 100 binaries, even with diffs still takes longer than uprating a single library, which means increased downtime during system updates. potentially increased security risks, yes. although shared libraries are bigger security risks Code is code; how is shared linking a greater risk? Have any data to back that up? i made an acc just to reply to this. why do people never understand static linking ? I understand static linking quite well, since my day job is part of a commercial OS team that coincidentally pioneered dynamic linking technology in UNIX. So let's not base our arguments on assumptions about knowledge just because we disagree.

gens 11y ago
>Most OS linkers already do efficient loading of only the relevant portions of a shared library since they typically mmap the library file. a page is 4kB (on x86 at least). a function is typically, what, 60 bytes ? 120 maybe ? 240 ? some functions use other functions (fopen()->_open() in libc) so you can have more then two pages maybe you are thinking about swapping (or not even lazy loading in the block layer) ? code has to be in RAM, everything else is insecure >In aggregate, static linking the same dependency for multiple programs will increase memory usage as well despite your assertions to the contrary since the pages will not generally be shared (yes, I'm aware some OS have page dedup or compression, etc., but I'm talking about the general case here). not pages, functions (and/or variable objects). when you make a .la on unices you are making a ar(1) archive out of .o object files. when the linker is linking the final binary it opens that .la archive and pulls out the relevant .o objects so "statically linking to properly(!) made libraries" will reduce overall memory usage, unless a lot of programs use that (small) library (rarely the case) OSX linker does the right thing with their libc. in that out of the many optimized memcpy()'s it will only load the one that is fast on the particular cpu GNU linker loads them all >Code is code; how is shared linking a greater risk? Have any data to back that up? data to back it up ? do you have any data to back up anything you said ? LD_PRELOAD can be used to replace functions and the user/admin would not notice it. while the only security flaw with static linking is an administrative mistake >I understand static linking quite well, since my day job is part of a commercial OS team that coincidentally pioneered dynamic linking technology in UNIX. >So let's not base our arguments on assumptions about knowledge just because we disagree. so go ask them about it

gens 11y ago

>Most OS linkers already do efficient loading of only the relevant portions of a shared library since they typically mmap the library file. a page is 4kB (on x86 at least). a function is typically, what, 60 bytes ? 120 maybe ? 240 ? some functions use other functions (fopen()->_open() in libc) so you can have more then two pages maybe you are thinking about swapping (or not even lazy loading in the block layer) ? code has to be in RAM, everything else is insecure >In aggregate, static linking the same dependency for multiple programs will increase memory usage as well despite your assertions to the contrary since the pages will not generally be shared (yes, I'm aware some OS have page dedup or compression, etc., but I'm talking about the general case here). not pages, functions (and/or variable objects). when you make a .la on unices you are making a ar(1) archive out of .o object files. when the linker is linking the final binary it opens that .la archive and pulls out the relevant .o objects so "statically linking to properly(!) made libraries" will reduce overall memory usage, unless a lot of programs use that (small) library (rarely the case) OSX linker does the right thing with their libc. in that out of the many optimized memcpy()'s it will only load the one that is fast on the particular cpu GNU linker loads them all >Code is code; how is shared linking a greater risk? Have any data to back that up? data to back it up ? do you have any data to back up anything you said ? LD_PRELOAD can be used to replace functions and the user/admin would not notice it. while the only security flaw with static linking is an administrative mistake >I understand static linking quite well, since my day job is part of a commercial OS team that coincidentally pioneered dynamic linking technology in UNIX. >So let's not base our arguments on assumptions about knowledge just because we disagree. so go ask them about it