Subject: Re: Please Please Plase :-)

From: [email-masked] (Theodore Ts'o)
Date: Tue, 14 Apr 92 01:05:31 -0400

Date: Mon, 13 Apr 92 11:35:03 +0100
   From: Damiano Bolla <[email-masked]>

   Can ve have a new subtree for linux that has gcc2 + the stuff
   compiled with gcc2 ( They need the libarary )

   SOmething like
   linux1.0/......

For right now, I would much rather request that people who are uploading
binaries to FTP sites *not* upload dynamically linked programs.  That
means they need to compile programs with the -static flag.  Even after
Linux 1.0 comes out (which it hasn't, yet), the dependency of which
shared library you need to use in order to win may still make it not
worthwhile to archive shared-library executables.  

If the ABC release takes off enough so that everybody is using the same
shared libraries, then perhaps it will work; I hope that is the case,
but I don't want to count on it.

In the mean time, please only upload statically linked programs to
TSX-11.  I think it will make people's lives much easier.

						- Ted

---

From: David Engel <[email-masked]>
Date: Tue, 14 Apr 92 9:27:51 CDT

> means they need to compile programs with the -static flag.  Even after

What about uploading "ready-to-be-linked" objects like we did with GCC 2.1
in 2.1shared-A.tar.Z?  This way, everybody gets to decide for themselves 
whether they want to use the shared libraries or not.  It is also nice for
handling library bugs because you can usually just relink when a new library
comes out.

David
-- 
David Engel                        Optical Data Systems, Inc.
[email-masked]                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

---

From: [email-masked] (Theodore Ts'o)
Date: Wed, 15 Apr 92 14:28:54 -0400

From: David Engel <[email-masked]>
   Date: Tue, 14 Apr 92 9:27:51 CDT

It is true that the "ready-to-be-linked" objects have the advantage that
you can relink when a new library comes out.  However.... this assumes
that people keep the .o files around --- which will either consume disk
space or time and bother to back them up to floppies.

Also, I'm not sure how convenient "ready-to-be-linked" objects really
are.  I suspect that people who are willing to go through the bother of
linking .o files are probably also willing to untar a source
distribution and compile it themselves.  True, a source distribution
takes more time to download, and takes a few extra seconds (but if you
have a fast 386/486 it is *only* few extra seconds, or minutes at most),
but I'm not convinced that there's enough of a difference between a
source distribution and .o files so that it is worthwhile to do both.

Binaries, on the other hand, you just download and go.  True, you have
to worry library bugs, and whether or not you have the right shared
library if you're using such beasts, but there are ways we can make that
easier.  For example, we could require that uploaded programs use only
statically linked libraries, or we could require that uploaded programs
be linked against some standard shared libc.a --- which wouldn't change
often.  (When it did change, people would have to keep the old shared libc
around until all of their binaries stopped using it; this means we want
to minimize the number of times the libc has to change.)  

So I'm not convinced that .o files are necessarily the right way to go.
I'm willing to be conviced, of course, but right now I think uploading
only statically linked binaries (and maybe shifting over to binaries
linked with a standard shared libc, once it stablizes) is the wisest
course.  People who feel otherwise are welcome to send me mail.  :-)

						- Ted