[1135] in SIPB_Linux_Development
Elf and other stuff
daemon@ATHENA.MIT.EDU (Salvatore Valente)
Tue Oct 31 00:08:38 1995
Date: Tue, 31 Oct 1995 00:05:29 -0500
To: linux-dev@MIT.EDU
From: Salvatore Valente <svalente@dimins.com>
It seems like Keesh gets less efficient as time goes on. It occured
to me that, at any given point, Keesh probably has all of the
following shared libs in memory: libc.4 (a.out), libc.5 (ELF) X11.6
(a.out), X11.6 (ELF), X11.3 (a.out). Each of these is over a meg.
This can't be a very good thing.
In order to require less shared libs:
- We should hunt down and destroy programs that were compiled with
X11R5 (libX11.so.3.) I've rebuilt the zephyr package, which was the
last Linux-Athena package to use libX11.so.3. Of course, there is
still /mit/*/linuxbin...
- For now, we should continue making stuff available in a.out format.
When somebody is wants to switch to ELF, they should be able to change
stuff and run an entirely-ELF system. Until then, they should be able
to run an entirely-a.out system. I've made most linux-athena packages
available in elf format in /mit/linux/elf-packages. Again,
/mit/*/linuxbin is still a problem.
Sigh. Maybe it would be a good idea to have separate bin directories
for linux-a.out and linux-elf in lockers. That would be such a pain,
though...
- It is a bad idea to try to have a system that can build both a.out
and ELF binaries. (Why? Think about things like -L/usr/X11/lib and
-L/usr/athena/lib...) It is easiest to simply have two separate build
engines, one for a.out and one for ELF.
I have reverted gcc, binutils, and libc on Keesh, so that it now
produces a.out binaries. It can still run ELF binaries, including
ones that use shared X and Motif libs, but it can't build them. For
now, Keesh can be Sipb's a.out build engine and Limekiller can be
Sipb's ELF build engine.
Hmm... Two build engines... Two $bindirs... I'm beginning to wonder
if it's really worth the time and resources. Maybe we should just
drop this linux-dev thing and tell people to use NetBSD.
Have a nice day.
-Sal.
P.S. About the "hunt and destroy" thing: You can use "ldd" to find
out what shared libs a program uses. Does anyone know if there's a
utility to tell you what shared libs you currently have in memory?
And, for that matter, is it really a big deal to have both libc.4 and
libc.5 in memory?
