Subject: Linux-Activists Digest #36
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 7 Apr 92 04:15:10 EDT

Linux-Activists Digest #36, Volume #2             Tue, 7 Apr 92 04:15:10 EDT

Contents:
  Re: IMPORTANT: gcc 2.1, libc.a 2.1a and Linux (Paul Allen)
  Re: Binaries considered harmful (Brett McCoy)
  Re: Second 0.95a alpha-patch (Hongjiu Lu -- Graduate Student)
  Re: Second 0.95a alpha-patch (Hongjiu Lu -- Graduate Student)
  Re: Binaries considered harmful (Hongjiu Lu -- Graduate Student)
  Re: Binaries considered harmful (Drew Eckhardt)
  Re: Compilers (Michael Haardt)
  Re: Compilers (Michael Haardt)

----------------------------------------------------------------------------

From: Paul Allen <[email-masked]>
Subject: Re: IMPORTANT: gcc 2.1, libc.a 2.1a and Linux
Reply-To: [email-masked]
Date: Tue, 7 Apr 1992 07:00:08 GMT

Greetings,

I sent mail to Hongjiu Lu ([email-masked]) asking for
clarification on the use of the new 2.1 compiler with the new
ld versus the old ld.  I wasn't sure how to get from 0.95a to
a usable setup with the new compiler.  I got the following 
helpful reply, along with a request to post it to the net.  It
answered my questions.  I hope it helps others.

Paul Allen
[email-masked]

===== Begin Included Message =====

| 
| H.J.,
| 
| You wrote:
| 
| >I heard there were some problems with binaries linked with my new ld.
| >That is caused by the new a.out.h introduced with Linus's second patch.
| >The new a.out.h is compatible with the old one, But not vice versa.
| 
| This is unfortunate, but I'm following you so far.
| 
| >My new ld (binutils.tar.Z) uses the new a.out.h. The binaries
| >linked by it can only run under the kernel with Linus's second patch,
| >which has to be built by the old ld.
| 
| OK, let's see if I've got it straight to this point.  Binaries linked
| by the new ld will not run under the 0.95a kernel, so I need to apply
| the patches to the sources and compile a new kernel.  Will the new 2.1
| gcc run under the 0.95a kernel?  Or do I need the 1.40 gcc in order to

The new gcc 2.1 is compiled with old ld. So it runs fine.

| get myself to a point where I can use 2.1?  (I'm getting ready to move
| about 25Mb of Linux stuff home on floppies, and I'd like to get it
| right the first time.  :-))
| 

Use my old ld and gcc 2.1 (beta) to compile 0.95a kernel with Linus's
second patch applied. You also need my 2.1kernel.tar.Z and 2.1ps.tar.Z
to compile kernel.

| >Any programs using the old a.out.h, e.g., gdb, will not recognize the
| >binaries linked by the new ld. You can either use the old ld or use
| >the new version compiled with the new a.out.h.
| 
| Hmmm...  Do you mean the new ld compiled with the new a.out.h?  Or the

Yes.

| new gdb compiled with the new a.out.h?  Or a new version of the program

Get new gdb compiled with the new a.out.h to debug programs linked with
my new ld.

| being debugged by gdb compiled with the new a.out.h?  Do I sound
| confused?  (Well, I guess I am.  :-))
| 

You do. What I mean is old gdb will only work with programs linked
with old ld. To debug  programs linked with new ld, you must use gdb
compiled with the nnew a.out.h.

| >>From Linus's second patch, we are moving to VFS. As a result, there
| >will be some changes in libc.a. That means next release of gcc 2.x and
| >libs will not run under the kernel below Linus's second patch to 0.95a.
| >I strongly recommend you move to 0.95a with Linus's second patch if you
| >haven't done so.
| 
| That's fair warning.  Thanks.  If I'm the only confused soul out here,
| could you send me a note clarifying things for me.  If I'm not the only
| confused soul, perhaps you could post a short note to the newsgroup?
| 
| Thanks for all the work you've done on gcc.  It is appreciated!
| 
| Paul Allen
| [email-masked]
| 

Could you please forword this to news groups?

H.J.
-- 
School of EECS                          Internet: [email-masked]
Washington State University             BITNET:   [email-masked]
Pullman, WA 99164                       Phone:    (509) 335-6470 (O)
USA                                               (509) 334-6315 (H)

===== End Included Message =====

------------------------------

From: [email-masked] (Brett McCoy)
Subject: Re: Binaries considered harmful
Date: 7 Apr 92 05:57:16 GMT
Reply-To: [email-masked]

In article <[email-masked]> Paul Allen <[email-masked]> writes:

   I may be missing something really obvious here, but I just don't see
   the need for all these binaries.  I'd rather just have sources.  With
   the exception of a few things that simply couldn't be compiled, Minix
   has always been a source-only system.  (You got the binaries when you
   bought Minix, and sources/diffs from the net kept you current from then
   on.) I see no reason that Linux needs to work differently.  

I, for the most part, agree with this.  What I'd really like to see is
a full distribution of the standard UNIX utilities in binary form, and
the sources, or diffs the the GNU sources, for these programs right
along side them.  Most of the time you grab a binary of something, and
then can't find sources or diffs, and if you do they always seem to be
for some other version.  It's nice to be able to bring up a working
system without having to spend a couple days recompiling everything,
but I think I would prefer that to having something akin to DOS
(binaries only).

The great thing about Linux is that it is available in source form, so
you can play with it to your hearts content.  Why is everyone else so
reluctant to include their diffs and/or sources with the binaries they
upload.  I for one am reluctant to just run any jo blow's binary.  How
long with it be before trojan horse or virus programs start to appear.
I know that most people blindly compile and run the sources, but if
things crash, and you go looking through the source and find trojan
code, you have proof and know where it came from.  With only the
binaries it is very hard to figure out what is going on.

++Brett;

------------------------------

From: [email-masked] (Hongjiu Lu -- Graduate Student)
Crossposted-To: alt.os.linux
Subject: Re: Second 0.95a alpha-patch
Date: 7 Apr 92 05:56:13 GMT

In article <[email-masked]> [email-masked] (Linus Benedict Torvalds) writes:
>I forgot to mention some of the changes this alpha-patch brings to the
>user: the kernel include-files have been slightly changed in a couple of
>cases, which can result in unexpected behaviour...
>
>a.out.h is now the latest GNU a.out.h, and it seems to have slightly
>different magic-number handling than the original 386-minix version I
>used for older versions.  Without recompiling the kernel with the new
>a.out.h, programs linked with the new binutils will not run (unable to
>execute binary file errors).  This just means that even if you don't use
>the patch in any other capacity, you had better upgrade to the new
>a.out.h, or newer programs won't necessarily run.  Right now there are
>no such binaries available, but when gcc2 gets more used, they will show

Ld in binutils.tar.Z with gcc 2.1 beta will produce such binaries.

>up. 
>
>The other change is that limits.h and sys/dirent.h are now part of the
>kernel include-files: they were needed for the readdir() system call. 
>Normally this wouldn't change anything, but there is also a slight
>change in limits.h - NAME_MAX is now defined to be 255 so that linux
>will eventually handle filesystems with longer names than 14 chars. 
>This means that the old direntry-routines in the library won't compile
>correctly, as they depended on NAME_MAX being the size of a directory
>name.  I hope the gcc-2 library won't have this problem, and that we can

I am changing it to sys call of readdir. But telldir and seekdir are
missing.

>move over to the more general readdir-function without undue growing
>pains. 
>
>The a.out.h change was made just to minimize the differences between the
>linux headers and the library headers - but the second change is pretty
>fundamental.  If you are porting software with the old libraries, I'd
>suggest keeping to the old limits.h in /usr/include - that way nothing
>should break until we get non-minix filesystems.  Adventurous people
>might want to test out the new kernel functions that will be supported
>even with new filesystems. 
>
>In case anyone is wondering why the NAME_MAX change is needed, it's due
>to the fact that the old /library/ readdir only handled a 14-char
>library entry.  When the VFS code is enhanced to allow different
>filesystems, you no longer can depend on this, and the library routine
>wouldn't know what type of directory it's supposed to read - so the code
>has to be moved into the kernel which knows about these things.  The new
>readdir() will work correctly independently of the underlying filesystem
>(so that you can freely mix different filesystems without needing to
>bother about it). 
>
>I'm sorry all this is certain to cause it's share of confusion (using
>the old library with the new NAME_MAX and vice versa), but there wasn't
>any graceful way to handle it all - unless I would have anticipated
>these problems from the start, which I didn't...  You can console
>yourselves with the thought that linux should be able to handle longer
>filenames and >64MB partitions within a couple of releases. 
>
>               Linus

Keep a copy of .a for each program you compile. You can link it against
any libraries (for now no telldir and seekdir).

H.J.

------------------------------

From: [email-masked] (Hongjiu Lu -- Graduate Student)
Crossposted-To: alt.os.linux
Subject: Re: Second 0.95a alpha-patch
Date: 7 Apr 92 05:56:13 GMT

In article <[email-masked]> [email-masked] (Linus Benedict Torvalds) writes:
>I forgot to mention some of the changes this alpha-patch brings to the
>user: the kernel include-files have been slightly changed in a couple of
>cases, which can result in unexpected behaviour...
>
>a.out.h is now the latest GNU a.out.h, and it seems to have slightly
>different magic-number handling than the original 386-minix version I
>used for older versions.  Without recompiling the kernel with the new
>a.out.h, programs linked with the new binutils will not run (unable to
>execute binary file errors).  This just means that even if you don't use
>the patch in any other capacity, you had better upgrade to the new
>a.out.h, or newer programs won't necessarily run.  Right now there are
>no such binaries available, but when gcc2 gets more used, they will show

Ld in binutils.tar.Z with gcc 2.1 beta will produce such binaries.

>up. 
>
>The other change is that limits.h and sys/dirent.h are now part of the
>kernel include-files: they were needed for the readdir() system call. 
>Normally this wouldn't change anything, but there is also a slight
>change in limits.h - NAME_MAX is now defined to be 255 so that linux
>will eventually handle filesystems with longer names than 14 chars. 
>This means that the old direntry-routines in the library won't compile
>correctly, as they depended on NAME_MAX being the size of a directory
>name.  I hope the gcc-2 library won't have this problem, and that we can

I am changing it to sys call of readdir. But telldir and seekdir are
missing.

>move over to the more general readdir-function without undue growing
>pains. 
>
>The a.out.h change was made just to minimize the differences between the
>linux headers and the library headers - but the second change is pretty
>fundamental.  If you are porting software with the old libraries, I'd
>suggest keeping to the old limits.h in /usr/include - that way nothing
>should break until we get non-minix filesystems.  Adventurous people
>might want to test out the new kernel functions that will be supported
>even with new filesystems. 
>
>In case anyone is wondering why the NAME_MAX change is needed, it's due
>to the fact that the old /library/ readdir only handled a 14-char
>library entry.  When the VFS code is enhanced to allow different
>filesystems, you no longer can depend on this, and the library routine
>wouldn't know what type of directory it's supposed to read - so the code
>has to be moved into the kernel which knows about these things.  The new
>readdir() will work correctly independently of the underlying filesystem
>(so that you can freely mix different filesystems without needing to
>bother about it). 
>
>I'm sorry all this is certain to cause it's share of confusion (using
>the old library with the new NAME_MAX and vice versa), but there wasn't
>any graceful way to handle it all - unless I would have anticipated
>these problems from the start, which I didn't...  You can console
>yourselves with the thought that linux should be able to handle longer
>filenames and >64MB partitions within a couple of releases. 
>
>               Linus

Keep a copy of .a for each program you compile. You can link it against
any libraries (for now no telldir and seekdir).

H.J.

------------------------------

From: [email-masked] (Hongjiu Lu -- Graduate Student)
Subject: Re: Binaries considered harmful
Date: Tue, 7 Apr 92 06:27:17 GMT

In article <[email-masked]> [email-masked] writes:
>(Subject line with appologies to E. Djikstra.  :-))
>
>I have a proposal that I'd like people to consider.
>
>I've been following Linux from the sidelines since last year sometime.
>I've noticed that with each release some of the old binaries from the
>previous release no longer work.  When people ask why some command or
>other no longer works, the answer is often to recompile with the new
>library, or with the new include files.  It seems to me that having
>lots of old binaries around on the archive sites is causing more 
>problems than it's worth.  Clearly, you need to have binaries for the
>compiler and enough commands to bootstrap a system.  I think it's
>counterproductive in the long run to distribute binaries for commands
>that are not essential for bootstrapping.  They'll all eventually
>be broken by some new release.
>
>So here's my proposal:
>
>- In addition to the binary boot and root images that currently 
>  accompany new releases, a companion tarfile should be released
>  containing things like the compiler for that release and other
>  stuff that was too large to fit in the root image.
>
>- Software that is not needed for bootstrapping should be placed in the
>  archives in source or diff form only.
>
>- Part of the process of installing a new Linux release is to recompile
>  everything.
>
>I may be missing something really obvious here, but I just don't see
>the need for all these binaries.  I'd rather just have sources.  With
>the exception of a few things that simply couldn't be compiled, Minix
>has always been a source-only system.  (You got the binaries when you
>bought Minix, and sources/diffs from the net kept you current from then
>on.) I see no reason that Linux needs to work differently.  
>
>I invite your comments, criticisms, flames, or whatever.
>
>Paul Allen
>[email-masked]

My proposal is use .a instead of binary to distribute most of programs.
The .a is more stable than binary. When a new library is out, you just
need to

        gcc -o foo foo.a -lneededbyfoo

Take a look at 2.1shared-A.tar.Z. They are all .a's. You can link them
against any libraries, shared, static or update.

Of course, you need gcc and ld.

H.J.

------------------------------

From: [email-masked] (Drew Eckhardt)
Subject: Re: Binaries considered harmful
Date: Tue, 7 Apr 1992 07:46:14 GMT

In article <[email-masked]> [email-masked] writes:
>(Subject line with appologies to E. Djikstra.  :-))
>
>I have a proposal that I'd like people to consider.
>
>I've been following Linux from the sidelines since last year sometime.
>I've noticed that with each release some of the old binaries from the
>previous release no longer work.  When people ask why some command or
>other no longer works, the answer is often to recompile with the new
>library, or with the new include files.  It seems to me that having
>lots of old binaries around on the archive sites is causing more 
>problems than it's worth.  Clearly, you need to have binaries for the
>compiler and enough commands to bootstrap a system.  I think it's
>counterproductive in the long run to distribute binaries for commands
>that are not essential for bootstrapping.  They'll all eventually
>be broken by some new release.
>

Other than programs which depend on the internal structure of 
Linux (this would be the ps packages, the file system utilities
such as fdisk, etc), what programs have broken with new releases of 
Linux?  

Some programs suffered because of bad library functions, 
and needed recompiling, but there's  a difference 
between one person recompiling at several hundred.

Except for files I have corrupted, or that were broken 
in the first place and subsequently fixed, much of what 
I'm using is from the .11 distribution (the file
utilities, bash until just recently, awk, sed, make, etc).  I 
had been compiling my kernel with the original 'C' compiler 
until 2.1 offered C++ and shared libaries, sufficient 
incentive to switch.

>So here's my proposal:
>
>- In addition to the binary boot and root images that currently 
>  accompany new releases, a companion tarfile should be released
>  containing things like the compiler for that release and other
>  stuff that was too large to fit in the root image.

The difficulty with one big tar file is in downloading it,
passing it through your internet site without incuring the wrath
of the sysadmins and disk quotas,  transfering it on floppy 
disks, etc.

>- Software that is not needed for bootstrapping should be placed in the
>  archives in source or diff form only.

I'm glad you have the disk space and time to spare.  I don't. 
The last time I built gcc, it used over 30M of disk space.  The last time
I built X, it took close to 200M of disk space, and 24 hours to 
build on a 50Mhz 68030 with 16M of real memory (This is somewhat longer 
than it had to be, as the 
disks were NFS mounted).  X is an extreme case, but exemplifies the
kind of software that people will be running on Linux as it becomes
more refined, stable, and popular.

The smaller programs (shell utils, file utils, mtools, elvis / micro
emacs) can be dealt with, but it is still more convienient for users 
to have a binary available so they don't have to do it themselves.

>- Part of the process of installing a new Linux release is to recompile
>  everything.
>

When I've installed a new linux release, it's 
consisted of getting the new boot image, getting the new kernel
source, and performing the following procedure : 

cd /usr/tmp 
tar xvf /dev/b1.44 

zcat /usr/tmp/bootimage* > /vmunix+

Reboot vmunix+. If it works, untar the sources, 
add in my favorite patches, do a make (About 8 
minutes with the old C compiler on a 386-33), and boot 
/usr/src/linux/Image.

If that works

mv /vmunix /vmunix- 
mv /usr/src/linux/Image /vmunix

The only thing this has ever broken was the simple ps package.

>I may be missing something really obvious here, but I just don't see
>the need for all these binaries.  I'd rather just have sources.  With
>the exception of a few things that simply couldn't be compiled, Minix
>has always been a source-only system.  (You got the binaries when you
>bought Minix, and sources/diffs from the net kept you current from then
>on.) I see no reason that Linux needs to work differently.  
>
>I invite your comments, criticisms, flames, or whatever.
>
In conclusion : 

1.  Things are not as unstable as you claim they are, and I would 
        venture to say that most upgrades are in pursuit of 
        having the latest, neat new features, or bug fixes to
        the source.

2.  Binary distributions are significantly smaller than
        source distributions, take less time to
        download, less disk space, and less time
        because they don't need to be compiled.

An example of a mid size program, gdb, in source and 
binary distributions.  The binary is ~800k uncompressed,
the source 8M, ten times as large.  

-rw-r--r--   1 drew     wheel     3105370 Apr  2 01:24 gdb-4.4.tar.Z
-rw-r--r--   1 drew     linux      469777 Mar 11 02:06 gdb-4.4.tar.Z 

3.  Linux is getting real users, not hackers.  These people 
        want something that works like DOS, they
        see something they like, grab it from their 
        favorite BBS, and run it.  Period.      

        I'm not saying that it's a good thing, 
        but given the little trouble it takes, 
        it's not a bad thing to offer a binary 
        distribution for these people.

Source should be freely available to anyone who wants it, 
but a more convienient binary distribution should also
be available.

------------------------------

Crossposted-To: alt.os.linux
From: [email-masked] (Michael Haardt)
Subject: Re: Compilers
Reply-To: [email-masked] (Michael Haardt)
Date: Mon,  6 Apr 92 22:27:02 +0100

From article <[email-masked]>, by gandalf! (Fred):
> What is going to happen with compilers under Linux? We have gcc1.40 with
> problems in the libraries. Then we have gcc2.x that is broken as well.
And we will get 2.1 with libraries.  Be patient for a while, all known
problems will be exchanged with new and more interesting ones :-)

> The other thing that people out there may be forgetting is that there are
> some of us that only have 2M ram, and cant afford to spring for more ram, and
> the move to 2.x will leave us in the cold.
Right, I have 2 MB and I can't afford to buy a new motherboard, mine is toooo
old and this special custum memory expansion cards are disappeared from world.
(I need Micronics/Compaq compatible sandwich boards, any offers?)

So I will have to live some some swapping.  Remember, it still works.  I
could also buy a cheap 16 bit memory expansion card, but haven't checked
that yet.  Or I could invest some work trying to implement a better
paging strategy.

Where are the problems?  Beta means beta == brandnew and interesting,
may need additional work.  Use Emacs without cursor keys, return or
backspace key (use Control J and Control H) and some bugs in memory
management on a keyboard with totally different layout than labeled for
a while to develop a better version, and you wouldn't complain about
these *minor* problems with compilers :)

Michael

------------------------------

Crossposted-To: alt.os.linux
From: [email-masked] (Michael Haardt)
Subject: Re: Compilers
Reply-To: [email-masked] (Michael Haardt)
Date: Mon,  6 Apr 92 22:27:02 +0100

From article <[email-masked]>, by gandalf! (Fred):
> What is going to happen with compilers under Linux? We have gcc1.40 with
> problems in the libraries. Then we have gcc2.x that is broken as well.
And we will get 2.1 with libraries.  Be patient for a while, all known
problems will be exchanged with new and more interesting ones :-)

> The other thing that people out there may be forgetting is that there are
> some of us that only have 2M ram, and cant afford to spring for more ram, and
> the move to 2.x will leave us in the cold.
Right, I have 2 MB and I can't afford to buy a new motherboard, mine is toooo
old and this special custum memory expansion cards are disappeared from world.
(I need Micronics/Compaq compatible sandwich boards, any offers?)

So I will have to live some some swapping.  Remember, it still works.  I
could also buy a cheap 16 bit memory expansion card, but haven't checked
that yet.  Or I could invest some work trying to implement a better
paging strategy.

Where are the problems?  Beta means beta == brandnew and interesting,
may need additional work.  Use Emacs without cursor keys, return or
backspace key (use Control J and Control H) and some bugs in memory
management on a keyboard with totally different layout than labeled for
a while to develop a better version, and you wouldn't complain about
these *minor* problems with compilers :)

Michael

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.95a released on March 17, 1992

End of Linux-Activists Digest
******************************