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