[1392] in SIPB_Linux_Development
What goes in /mit/locker/arch/i386_linux1
daemon@ATHENA.MIT.EDU (Salvatore Valente)
Sun Aug 25 02:03:50 1996
Date: Sun, 25 Aug 1996 02:03:01 -0400
To: linux-dev@MIT.EDU
From: Salvatore Valente <svalente@MIT.EDU>
I talked to Derek about this for a few seconds today. We didn't agree.
In my opinion, in any Sipb or Linux-Dev supported locker, i386_linux1
should be a symlink to i386_linux2, or vice versa. It should contain
ELF executables linked with some version of libc 5.
I personally have no real preference between ELF or a.out. (I've
heard people say that libc 4 is much less buggy than libc 5, but I
haven't seen much evidence of this first hand.) It's simply a matter
of support. I have no interest in continuing this feeble attempt to
support both a.out and ELF. I don't want to keep telling people where
to get the appropriate compatability libraries. I don't want to keep
Keesh as an a.out build engine. I don't want to have to keep telling
people, it's an a.out vs. ELF compatability problem.
For simplicity, all libc 4 executables we can find in the Athena
environment should be desupported and nuked from orbit.
(Yes, this means that we'll have to help people who don't have libc 5
through the painful upgrade process. Which is a good idea anyway.)
It's not a contradiction in any way to have ELF executables in a
directory called i386_linux1. Libc 5/ELF was released under Linux 1.
Cutter has been using the i386_linux1 ELF system packs since the day
we got it. Some of the newer stuff in /mit/sipb/linuxbin is linked
with ELF libraries. Slackware 3.0, which has been the distribution of
choice for months, came with Linux 1.2.13 and libc 5. Many people
running older distributions installed libc 5 long before Linux 2.0
came out.
i386_linux1 and i386_linux2 are different but binary compatable
versions of the operating system, just like sun4c_51 and sun4c_52 are.
They should be treated the same way.
My two cents.
-Sal.
