* Andrei Mircea <mircea.andrei@wanadoo.fr>:
1) I know that static compiled programs are bigger but they do not fill a hard disk. In order to have more data about this, I tried to compile a few programs with -static (usually I go with the classical configure - make scheme). I did it with three programs I currently use: mc (Midnight Commander), mutt and lyx. While all three compile here without errors dynamically, with -static I got errors in all three. Only mc ignored them and produced an executable, the other two failed. In all cases the errors were related to functions in libintl. For mc the comparison is as follows: dynamic size 675192, static size 919995. This is no big deal, isn't it, no risk of exploding my hard disk.
You were lucky in your choice. For example, an unshared version of xterm has copies of the X libraries linked into it, and is 1411KB in size. The shared version is only 155KB in size! That is over 9 times larger. Explode indeed. Also, imagine if all of your X programs had their own copy of the X libraries compiled in. This means that instead of reusing it in RAM, you would have to load it into RAM several times. Same for libc, libxpm, libwhatever, etc.
2) As for the second reason, that's indeed the problem which arises most of the time and I see it in fact as an argument against dynamic linking. See what happens in the above tests, two out of three applications don't compile statically. The error criteria are obviously relaxed for dynamic linking, guess why ?
You misunderstand. Imagine if all of your programs were statically compiled with a buggy libc. This means you have to recompile *each and every one* to eliminate the bug. What do I have to do? Just get the new libc.
So, maybe there are "other reasons" (no doubt about that since dynamic linking has become the rule : there must be reasons), the ones that you give do not suffice to me, sorry.
You seem to want to explain away the reasons. Of course there are costs involved with dynamic linking, but the costs of static libraries are just more serious.
However, your explanation clearly outlines the problem and clearly shows how difficult it is to live in an open source community with the present approach. The approach you advocate is the Microsoft approach.
It's a *real* stretcher to call dynamic linking the "Microsoft approach". In light of the views of Joe Linux User, I assume you are attempting to associate something that you don't like with microsoft to make it look bad. Dynamically yours, david. -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/