Subject: re: emul/aout, compat/aout [was: Re: Upcoming releases]
To: Christos Zoulas <christos@zoulas.com>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: tech-userlevel
Date: 11/12/1999 14:44:19
On Thu, 11 Nov 1999, Christos Zoulas wrote:

> On Nov 11,  3:16pm, wrstuden@nas.nasa.gov (Bill Studenmund) wrote:
> -- Subject: re: compat/aout [was: Re: Upcoming releases]
> 
> Per Bill's request, I am posting this to tech-userlevel to solicit opinions:

Thanks!

> [the background here is we are trying to decide what to do about having
>  a.out compatibility in 1.5:
> 	- use the existing compat_aout which has the shadow tree resolution
> 	  problem
> 	- hack the ld.so to look in different places which has the migration
> 	  to /path/to/lib/aout problem
> ]

Right. People have started muttering about 1.5, and I think we need to
start working on this now.

> | On Thu, 11 Nov 1999, Christos Zoulas wrote:
> | 
> | > 
> | > It seemed like too much work to fix ld.so, and it was not very clear
> | > how to do it. For example, what do you do with paths outside /usr/lib
> | > like -R/usr/pkg/lib?  I also wanted to keep a.out stuff outside /usr/lib
> | > and not pollute the new elf stuff with old a.out files so it would be
> | > easier to cleanup. Plus it seemed ugly to me to have to versions of ld.so.
> | > What do you do? You compile it one way for the people that have converted
> | > to elf, and another way for the people that still run a.out?

I like the idea of having the aout libraries in a subdirectory. So for
instance if ld.so (or ld.aout_so) finds /foo/bar/libZ.so.*.* is an elf
lib, it looks at /foo/bar/aout/libZ.*.

I'm not sure if, given an -R/path, it should look at /path/aout first, or
if it should look at /path and roll over to /path/aout as above. I'd
suspect -R/path/aout, then /path if /path/aout doesn't exist.

I'm not sure what to do about finding a.out libs in /path if /path/aout
exists..

As for two ld's, don't we have two now?

Also, what about upgrading packages??

Take care,

Bill