Ian Murdock: No, I'm not saying this at all. I'm saying that fairly soon our primary emphasis (from a development point of view) will be the ELF distribution. We'll still update the a.out distribution, of course, but it'll become less and less of a priority from a development point of view. The most important aspect of having the a.out distribution will be its stability. It'll be the primary choice of users who need a stable distribution for a long time. The users who want to live on the "bleeding edge" will be using the ELF distribution the minute we start working on it.
As I understand it, the big functional difference between ELF and a.out formats is the nature of the shared libraries. ELF resolves names at runtime while a.out resolves names at compile time. Also, a.out requires libraries to always be mapped in to the same region of memory but elf allows this mapping to differ from program to program. [Thus, the a.out scheme restricts use of libraries.] This means that a.out trivially has compile-time support for multiple bindings for the same name -- this is great for backwards binary compatability, something Linux has excelled at. However, the cost is some significant complexity for developers of libraries. I'm not sure how elf handles this -- possibly the program specifies which version of the library it's looking for and there's an instancing scheme to select one of several releases of a function for cases where there's been an interface change. Last time I checked (and it's been a couple weeks) the upgrade plans for moving to an elf-based-linux were still in flux. Basically, there are lots of little issues to resolve before it can become a reality. Personally, I suspect that it should be possible to build a library that's both elf and a.out. It would probably require setting aside some special name in an elf name-space, and hardcoding some interface into the kernel to use that name under certain circumstances. [much hand waving here.] Then again, maybe not... -- Raul
