From: Digestifier To: Linux-Activists@news-digests.mit.edu Reply-To: Linux-Activists@news-digests.mit.edu Date: Tue, 7 Apr 92 04:15:10 EDT Subject: Linux-Activists Digest #36 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 Subject: Re: IMPORTANT: gcc 2.1, libc.a 2.1a and Linux Reply-To: paula@atc.boeing.com Date: Tue, 7 Apr 1992 07:00:08 GMT Greetings, I sent mail to Hongjiu Lu (hlu@yoda.eecs.wsu.edu) 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 pallen@atc.boeing.com ===== 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 | pallen@atc.boeing.com | Could you please forword this to news groups? H.J. -- School of EECS Internet: hlu@eecs.wsu.edu Washington State University BITNET: 60935893@WSUVM1.BITNET Pullman, WA 99164 Phone: (509) 335-6470 (O) USA (509) 334-6315 (H) ===== End Included Message ===== ------------------------------ From: brtmac@maverick.ksu.ksu.edu (Brett McCoy) Subject: Re: Binaries considered harmful Date: 7 Apr 92 05:57:16 GMT Reply-To: brtmac@maverick.ksu.ksu.edu In article <1992Apr7.054001.3797@athena.mit.edu> Paul Allen 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: hlu@yoda.eecs.wsu.edu (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 <1992Apr5.174430.17408@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (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: hlu@yoda.eecs.wsu.edu (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 <1992Apr5.174430.17408@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (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: hlu@yoda.eecs.wsu.edu (Hongjiu Lu -- Graduate Student) Subject: Re: Binaries considered harmful Date: Tue, 7 Apr 92 06:27:17 GMT In article <1992Apr7.054001.3797@athena.mit.edu> paula@atc.boeing.com 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 >pallen@atc.boeing.com 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: drew@caesar.cs.colorado.edu (Drew Eckhardt) Subject: Re: Binaries considered harmful Date: Tue, 7 Apr 1992 07:46:14 GMT In article <1992Apr7.054001.3797@athena.mit.edu> paula@atc.boeing.com 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: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) Subject: Re: Compilers Reply-To: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt) Date: Mon, 6 Apr 92 22:27:02 +0100 From article <1992Apr6.015643.22610@ucc.su.OZ.AU>, 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: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) Subject: Re: Compilers Reply-To: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt) Date: Mon, 6 Apr 92 22:27:02 +0100 From article <1992Apr6.015643.22610@ucc.su.OZ.AU>, 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: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux) via: Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU 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 ******************************