[SLE]Re: back to static compiled applications ?
Looking for consensus, I can marginally agree with your third reason, not with the first two. 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. 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 ? 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. 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. With due consideration to the fact that companies like SuSE, Redhat, earn their lives on it, I will not say it's bad - simply I don't like... On Tue, Jun 27, 2000 at 06:42:11AM +0200, Philipp Thomas wrote:
* Andrei Mircea (mircea.andrei@wanadoo.fr) [20000627 01:59]:
Given the huge RAM memory available in present computers, I wonder if it would not be more reasonable to go back to the old system of statically linked programs. Dynamic linking sure is a bright idea, but...what do other people on this list think ?
Thats a very bad idea, for a number of reasons.
- The needed disk space would explode. To see the difference, just compile your favourite app with -static added to the compiler options. - Updating the library would force recompiling/updating *all* applications. - Not every machine has huge amounts of RAM.
There are others but this should suffice.
The reason for the problems with shared libraries is, that most developers aren't cautious enough. What you need for such work is a defined environment for building binary packages. That's why our automatic package building system uses a chroot environment in which all necessary packages for a given distribution are installed. That way you get a defined set of tools and libraries that match the distribution for which a package is built.
Philipp
-- Philipp Thomas <pthomas@suse.de> Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany
-- 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/
* 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/
I took the applications I am interested in. After reading your message, out of curiosity I tried xiterm-1.0 (international xterm from an older suse distro which includes a sunsite mirror) and compiled static and dynamic executables. Indeed the static one turns out to be much larger than the dynamic one (780 vs. 68 kbyte ; didn't you forget to strip your executables ?). This is normal for an application like xterm which is small by itself and relies heavily on the subroutines taken from outside. However the size consideration is only relevant for the room on hard disk (which did not explode here under the weight of the additional 700 kbytes); when actually loaded in RAM, the program should take approximately the same room in RAM - the static version being favored since it has less overhead. To check this in the case under discussion, I looked at the output of free: used free shared no xiterm 110800 17024 33300 xiterm-static 111852 15972 34736 xiterm-dynamic 111976 15848 35180 I think this proves my point. Concerning the stuff about Microsoft etc: I don't intend to harm any one person in particular with my thoughts on static vs. dynamic linking, however, it seems to me that commercial considerations are indeed among the "other reasons". What do you think ? Statically yours, Andrei On Wed, Jun 28, 2000 at 09:03:55AM -0600, David Porter wrote:
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.
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/faq
On Sun, 2 Jul 2000, Andrei Mircea wrote:
I took the applications I am interested in. After reading your message, out of curiosity I tried xiterm-1.0 (international xterm from an older suse distro which includes a sunsite mirror) and compiled static and dynamic executables. Indeed the static one turns out to be much larger than the dynamic one (780 vs. 68 kbyte ; didn't you forget to strip your executables ?). This is normal for an application like xterm which is small by itself and relies heavily on the subroutines taken from outside. However the size consideration is only relevant for the room on hard disk (which did not explode here under the weight of the additional 700 kbytes); when actually loaded in RAM, the program should take
There are places where statically linked executables are beneficial. But you can't possibly justify making every app on your system static? 10 times the size would make my HD explode. Greg -- 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/faq
I did not suggest that. It all depends on the kind of use you put your computer to. In my case, I don't use hundreds of applications, only a few tens, out of which maybe about ten are critical for me. Even in this case, I wont't touch an application which never bothered me. But for those applications which are really critical for me I think I will try and go static as much as possible, since anyway I compile them myself to make sure there are no hidden problems. Moreover, as seen from the few examples discussed in this thread, the big applications don't grow so much with static linking: I got only about 50% increas for lyx and mc. Only xterm grew much more but this is because it starts very small with dynamic linking (most of the procedures it uses are in the different general libraries). I would like to read more documented arguments in the favour of dynamic linking. On Sun, Jul 02, 2000 at 09:54:34AM -0700, Greg Thomas wrote:
There are places where statically linked executables are beneficial. But you can't possibly justify making every app on your system static? 10 times the size would make my HD explode.
-- 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/faq
At 22:39 02/07/00, you wrote:
I did not suggest that. It all depends on the kind of use you put your computer to.
Agreed. Does raise the question though, where all the statically linked programs from /sbin have gone. The -s- in /sbin is for "static" for a good reason: A system admin in distress would be very pleased to have his emergency programs be statically linked and available from /sbin. It seems distibutors have been leaving this path since ages. Anyone knows which o.s. holds this old SVR4 adagium? Linux does not, Solaris does a bit, UnixWare not that I know off, AIX not that I know off. Pity... Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available -- 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/faq
Koos Pol wrote:
At 22:39 02/07/00, you wrote:
I did not suggest that. It all depends on the kind of use you put your computer to.
Agreed. Does raise the question though, where all the statically linked programs from /sbin have gone. The -s- in /sbin is for "static"
This is a common misinterpretation of the 's' in "/sbin" The 's' stands for "system" and is designated to contain "non-essential system binaries" not to be used by "ordinary" users (cf. the /sbin section in the FHS). As executables in /sbin often are executed in single-user mode, without having optional filesystems mounted, binaries under /sbin may not be dynamically linked against libraries in secondary (eg. /usr/lib) or optional filesystem hierarchies (eg. /opt/kde/lib) *or* have to be statically linked. Under Linux, this in practice means that binaries under /sbin can be dynamically linked against libraries below /lib but not be dynamically linked against libraries located elsewhere. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de -- 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/faq
Hi all, I want to setup Sendmail for my Intranet ...Can anyone point me to a good tutorial on the web ..like say, Jun Da's tutorial for PHP3, Apache & MySQL :-) Best Regards Anurag -- 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/faq
Hi Anurag They have a lot of info on www.sendmail.org Chris On Mon, 03 Jul 2000 17:44:46 +0530, Anurag Jalan wrote:
Hi all,
I want to setup Sendmail for my Intranet ...Can anyone point me to a good tutorial on the web ..like say, Jun Da's tutorial for PHP3, Apache & MySQL :-)
Best Regards
Anurag
-- 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/faq
-- 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/faq
Hi , I've downloaded the latest sendmail.8.10.2.tar.gz and a signature file sendmail.8.10.2.tar.sig.. what do i do with the latter ? Thanks to this list , i have a couple of great tutorials to refer to ! I suppose i need to uninstall the sendmail 8.9.3 rpms that came with my distro .? Thanks Anurag -- 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/faq
At 05:44 PM 07/03/00 +0530, Anurag Jalan wrote:
I want to setup Sendmail for my Intranet ...Can anyone point me to a good tutorial on the web
I found this helpful: http://www.linuxgazette.com/issue45/pollman/mail.html That may also be on your SuSE distribution. I found it less confusing (for me) to start from scratch and build sendmail and use my own .mc file instead of using the SuSE setup. Bill Moseley mailto:moseley@hank.org -- 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/faq
At 13:41 03/07/00, Ralf Corsepius wrote:
Koos Pol wrote:
The -s- in /sbin is for "static"
This is a common misinterpretation of the 's' in "/sbin" The 's' stands for "system"
Now I wasn't an admin in the 70's or 80's yet, so I can't speak from experience, but a least this is not what I have learned in my SVR4 course. My course says the -s- is for "statically". At this this guy (http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=500170437&CONTEXT=962630392.801046616&hitnum=112) seems to agree with me :-) Also, some more pointers: http://www.enteract.com/~lspitz/armoring.html http://www.yggdrasil.com/bible/bible-src/sag-0.2/sag/node9.html And now if I could only find the original remarks at Bell Labs when they where firing it all up... :-) Cheers, Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available -- 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/faq
The -s- in /sbin is for "static"
This is a common misinterpretation of the 's' in "/sbin" The 's' stands for "system"
Now I wasn't an admin in the 70's or 80's yet, so I can't speak from experience, but a least this is not what I have learned in my SVR4 course. My course says the -s- is for "statically". At this this guy (http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=500170437&CONTEXT=962630392.801046616&hitnum=112) seems to agree with me :-)
Also, some more pointers: http://www.enteract.com/~lspitz/armoring.html http://www.yggdrasil.com/bible/bible-src/sag-0.2/sag/node9.html
I checked all three of those links and none of them say what the -s- in sbin stands for. (Unless I missed it.) They just say the directory contains statically linked executables. Which is crap. All the exectuables in my SuSE-6.2 /sbin directory have a dynamically linked libc.so, except for the dozen or so shell scripts which aren't linked against anything - statically or otherwise. I, like the previous poster, thought the -s- stood for system or superuser. Whever history or your course tutor says, this is the sensible interpretation on a modern UNIX. Now, I must get back to work because this thread is absolutely, utterly and totally irrelevant! ;-> -- 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/faq
At 17:17 03/07/00, you wrote:
I checked all three of those links and none of them say what the -s- in sbin stands for. (Unless I missed it.) They just say the directory contains statically linked executables. Which is crap. All the exectuables in my SuSE-6.2 /sbin directory have a dynamically linked libc.so, except for the dozen or so shell scripts which aren't linked against anything - statically or otherwise.
Although I respect your opinion, (my opinion is an opinion likewise), you can't be serious taking SuSE as reference in a 25 years of Unix history. Now as I am still looking for the original Bell Labs remarks on this stuff, it should be fun to see if someone has an old Unix system hanging around and can check what files are in /sbin :-) Cheers, Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available -- 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/faq
I, like the previous poster, thought the -s- stood for system or superuser. Whever history or your course tutor says, this is the sensible interpretation on a modern UNIX.
Altought modern Unix's can easily have changed points of view and practical implementations, /sbin got it's name back in the old days. So what we think as being sensible today is not really an argument for the validity of forgone choices.
Now, I must get back to work because this thread is absolutely, utterly and totally irrelevant! ;->
Boy what a way to start my working day! More! More! MORE GIVE ME MORE! Cheers, Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available -- 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/faq
Hello, Guys! Can I have some libraries compiled statically into my executable, and some dynamically? Thanks, George. -- 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/faq
Can I have some libraries compiled statically into my executable, and some dynamically?
Yes. -- 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/faq
How? On Tue, 4 Jul 2000, Derek Fountain wrote:
Can I have some libraries compiled statically into my executable, and some dynamically?
Yes.
-- 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/faq
-- 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/faq
Just name the libraries on your link line. Static ones (libxxx.a) will be linked statically, dynamic ones (libxxx.so) will be linked dynamically. If you have both static and dynamic versions of a library I think the dynamic one is chosen, but you might want to check on that.
How?
On Tue, 4 Jul 2000, Derek Fountain wrote:
Can I have some libraries compiled statically into my executable, and some dynamically?
Yes.
-- 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/faq
I've read in books that it was a place for programs used by su/root, so they added the "s". Koos Pol wrote:
At 13:41 03/07/00, Ralf Corsepius wrote:
Koos Pol wrote:
The -s- in /sbin is for "static"
This is a common misinterpretation of the 's' in "/sbin" The 's' stands for "system"
Now I wasn't an admin in the 70's or 80's yet, so I can't speak from experience, but a least this is not what I have learned in my SVR4 course. My course says the -s- is for "statically". At this this guy (http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=500170437&CONTEXT=962630392.801046616&hitnum=112) seems to agree with me :-)
Also, some more pointers: http://www.enteract.com/~lspitz/armoring.html http://www.yggdrasil.com/bible/bible-src/sag-0.2/sag/node9.html
And now if I could only find the original remarks at Bell Labs when they where firing it all up... :-)
Cheers,
Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available
-- 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/faq
-- 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/faq
I always heard it stood for "S(ystem)BIN(aries)" that or "S(melly)BIN"
I've read in books that it was a place for programs used by su/root, so they added the "s".
Koos Pol wrote:
At 13:41 03/07/00, Ralf Corsepius wrote:
Koos Pol wrote:
The -s- in /sbin is for "static"
This is a common misinterpretation of the 's' in "/sbin" The 's' stands for "system"
Now I wasn't an admin in the 70's or 80's yet, so I can't speak from experience, but a least this is not what I have learned in my SVR4
course.
My course says the -s- is for "statically". At this this guy
(http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=500170437&CONTEXT=962630392.801 046616&hitnum=112)
seems to agree with me :-)
Also, some more pointers: http://www.enteract.com/~lspitz/armoring.html http://www.yggdrasil.com/bible/bible-src/sag-0.2/sag/node9.html
And now if I could only find the original remarks at Bell Labs when they where firing it all up... :-)
Cheers,
Koos Pol
-- 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/faq
Good question. When starting this thread I did not have in mind these basic programs though. I was thinking about the application programs which are in /usr. But I agree that all system executables which are in the /bin and /sbin directories should be foolproof. On Mon, Jul 03, 2000 at 11:13:22AM +0200, Koos Pol wrote:
Agreed. Does raise the question though, where all the statically linked programs from /sbin have gone. The -s- in /sbin is for "static" for a good reason: A system admin in distress would be very pleased to have his emergency programs be statically linked and available from /sbin. It seems distibutors have been leaving this path since ages. Anyone knows which o.s. holds this old SVR4 adagium? Linux does not, Solaris does a bit, UnixWare not that I know off, AIX not that I know off. Pity...
-- 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/faq
participants (12)
-
a_jalan＠vsnl.com -
admin＠brevsville.com.au -
corsepiu＠faw.uni-ulm.de -
ethant＠pacificnet.net -
europax＠home.com -
fountai＠hursley.ibm.com -
jbarnett＠axil.netmate.com -
jcm＠bigskytel.com -
koos.pol＠nl.compuware.com -
mircea.andrei＠wanadoo.fr -
moseley＠hank.org -
sle＠mmts.nsys.by