On Feb 9, 12:32pm, cjones@rupert.honors.montana.edu (Chris Jones) wrote:
-- Subject: Re: ELF integration on a.out platforms

| >>>>> "Christos" == Christos Zoulas <christos@zoulas.com> writes:
| 
| Christos> 1. Static and _pic libraries.
| 
| Maybe it sounds callous, but why bother with them?  If the compiler is
| changed so that it outputs ELF objects, what good do the static a.out
| libraries do anybody?  Presumably, you're not going to be making any
| new a.out objects, and the ones that you have are already linked
| against the libs.  Can't we just replace the libraries with the ELF
| ones?

Not all libraries are dynamic. Changing the major numbers for 3rd party
libraries (X for example is major hassle).

| Christos> 2. Versioning problems with ld.so.cache for a.out
| 
| Again, I probably don't understand the full issues here.  But can't we
| have an ld.so.cache for a.out, and keep that separate from any similar
| ELF facility?  Why do they need to interfere with each other at all?
| Shouldn't the new major version number prevent old a.out binaries from
| linking against the ELF libc.so.13, since they were linked against
| libc.so.12?

There is no similar facility for ELF. The ld.so.cache gets created by scanning
the directory, so unless someone modifies it so that it skips no a.out
files, it will pick up the ELF ones.
| 
| Christos> 3. Confusion in a.out configuration programs.
| 
| I'm sorry, but I don't understand what you're referring to here.

Programs that use a.out tools, but try to find symbols in libraries in /usr/lib
by nm or compiling and linking like gnu autoconf.

| If all of this has already been discussed, please just tell me so, and
| point me at the archives.

No it has not been discussed.

christos