[SLE] back to static compiled applications ?

newer
[SLE] Dissaponted in SuSE update..

mircea.andrei＠wanadoo.fr

26 Jun 2000 26 Jun '00

21:37

I observe that 95 percent (at least) of the application installation problems are related to the inadequacy of some libraries. We spend our life downloading libraries and testing them. In an open source world, the average program developer uses some version of a library he or she happens to have in the computer at a given time. Then, they cross fingers and hope that their program will work with some other versions of those libraries, or, if they want to be on the safe side, they distribute their version with the application. I guess that I have more libraries than applications I really use on my machine... 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 ? -- 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/

Show replies by date

landie＠concentric.net

27 Jun 27 Jun

00:13

agree 100% On Mon, 26 Jun 2000, Andrei Mircea wrote:

...

I observe that 95 percent (at least) of the application installation problems are related to the inadequacy of some libraries. We spend our life downloading libraries and testing them. In an open source world, the average program developer uses some version of a library he or she happens to have in the computer at a given time. Then, they cross fingers and hope that their program will work with some other versions of those libraries, or, if they want to be on the safe side, they distribute their version with the application. I guess that I have more libraries than applications I really use on my machine... 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 ?

-- 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/

-- Rolando Roman icq 3783184 -- 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/

cees-list＠griend.xs4all.nl

12:25

On Mon, Jun 26, 2000 at 08:13:58PM -0400, Rolando Roman wrote:

...

agree 100%

On Mon, 26 Jun 2000, Andrei Mircea wrote:

...
I observe that 95 percent (at least) of the application installation problems are related to the inadequacy of some libraries.

Disagree 100%. Why do you think they invented shared libraries? Regards, Cees. -- 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/

europax＠home.com

28 Jun 28 Jun

00:32

Library problems have been a big problem for me, especially libjpeg and libgtk Rolando Roman wrote:

...

agree 100%

...

On Mon, 26 Jun 2000, Andrei Mircea wrote:

...
I observe that 95 percent (at least) of the application installation problems are related to the inadequacy of some libraries. We spend our life downloading libraries and testing them. In an open source world, the average program developer uses some version of a library he or she happens to have in the computer at a given time. Then, they cross fingers and hope that their program will work with some other versions of those libraries, or, if they want to be on the safe side, they distribute their version with the application. I guess that I have more libraries than applications I really use on my machine... 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 ?

-- 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/ -- Rolando Roman icq 3783184

-- 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/

-- 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/

pthomas＠suse.de

27 Jun 27 Jun

17:58

* 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 Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany #define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX for PDP 11, /usr/include/sys/param.h -- 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/

roberto＠orion.cl

18:08

New subject: [SLE] Host and host.equiv

Hello all, Meaby sound extrange, but someone can send me and examples of .Host and host.equiv archives, please??? Regards _________________________________ Atte, Roberto Poblete / email: roberto@orion.cl fono: 6403943 / Fax: 6403990 Orion 2000 Consultoría en Seguridad y Redes -- 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/

juergen.braukmann＠ruhr-west.de

20:38

New subject: [SLE] Host and host.equiv

Roberto Poblete wrote:

...

Hello all,

Meaby sound extrange, but someone can send me and examples of .Host and host.equiv archives, please???

Regards

for hosts.equiv use something like the following: # # hosts.lpd This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enought for allowing rsh(1) commands. # # hostname marvin.forty.two 192.168.42.42 what do you reffer to with .hosts? /etc/hosts?? looks like: 127.0.0.1 localhost 192.168.42.243 marvin.forty.two marvin 192.168.42.42 arthurdent.forty.two arthur etc. I'm susre there is a man page about... Juergen -- =========================================== __ _ Juergen Braukmann juergen.braukmann@gmx.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu | /\\ /__/ / _ \/ // /\ \/ / ===========================================_\_v __/_/_//_/\_,_/ /_/\_\ -- 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/

mircea.andrei＠wanadoo.fr

28 Jun 28 Jun

05:44

I succeeded compiling with static linking the last version of lyx (1.1.5). Here is the size data: dynamic linking 1,528,800 static linking 2,529,308 The hard disk did not explode and I have a stable executable which I can use without having to cross the fingers at the next upgrade of my system. Is this correct ? On Tue, Jun 27, 2000 at 07:58:47PM +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 Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

-- 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/

-- 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/

mike＠universe.ne.mediaone.net

13:06

Morning: I've seen a few messages go back and forth on this topic. Personally, I'm all in favor of static compiling. Yes, there are valid points raised about it making programs larger, etc. this is one of those "everyone is right" type scenarios. In the case of something like this, I think it's simply the users preference. If I have a large hard drive, lots of RAM, and I want to make things a little easier on myself, why not compile the source statically and be done with it? I can now take this to another Linux machine, and I don't have to be bothered with what the other user has installed, because I've got a self-contained unit. On the same token, I can't say anyone who is against this belief is wrong either. I saw a statement made by one user who said that programmers need to be more careful when writing code. This also has its merits, but I think it's a lot easier to work around the problem by statically linking what works, instead of trying to retrain a horde of programmers who may write code a little diferently depending on what library version they are linking against. Just my .02 :) - Mike On Wed, 28 Jun 2000, Andrei Mircea wrote:

...

Date: Wed, 28 Jun 2000 07:44:43 +0200 From: Andrei Mircea To: suse-linux-e@suse.com Subject: Re: [SLE] back to static compiled applications ?

I succeeded compiling with static linking the last version of lyx (1.1.5). Here is the size data: dynamic linking 1,528,800 static linking 2,529,308 The hard disk did not explode and I have a stable executable which I can use without having to cross the fingers at the next upgrade of my system. Is this correct ?

On Tue, Jun 27, 2000 at 07:58:47PM +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 Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

-- 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/

-- 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/

fountai＠hursley.ibm.com

15:15

...

I succeeded compiling with static linking the last version of lyx (1.1.5). Here is the size data: dynamic linking 1,528,800 static linking 2,529,308 The hard disk did not explode and I have a stable executable which I can use without having to cross the fingers at the next upgrade of my system. Is this correct ?

So, on one example, you have increased the size of the binary by 40%. This doesn't look right. Did you ensure you were statically linking libc? I suspect not (I don't even have a libc.a on my system - do you?) My libc6 shared object is about 4MB, so you have to add 4MB to each executable on your system. Hmmm... from my SuSE-6.4 system (which runs GNOME with KFM and several other KDE apps): /bin: 102 files in 6888K /usr/bin: 1455 files in 108760K /usr/X11R6/bin: 434 files in 38748K /opt/kde/bin: 462 files in 80708K /opt/gnome/bin: 196 files in 80868K So, my basic set of executables takes around 320MB. If I increase that by 40%, that's nearly 150MB extra disk space. OK the disk won't explode, but it's a reasonable chunk. If I statically link the 4MB libc file to each of my 2650 executables, that's another 10.5GB I need in order to store them. That might cause my 9GB disk to explode. More important to me is memory. My current system is running GNOME and is pretty much idle. It has 80 processes running. If they each had statically linked libraries each one would be about 5MB minimum - the X ones would be several times that. So, even without X, that's 400MB of RAM just to hold the executables on an idle system. If you want to run with statically linked binaries, you've got the source, so you go ahead. But this is an advance I could do without. -- 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/

8704

Age (days ago)

8706

Last active (days ago)

List overview

Download

9 comments

9 participants

participants (9)

cees-list＠griend.xs4all.nl
europax＠home.com
fountai＠hursley.ibm.com
juergen.braukmann＠ruhr-west.de
landie＠concentric.net
mike＠universe.ne.mediaone.net
mircea.andrei＠wanadoo.fr
pthomas＠suse.de
roberto＠orion.cl