On Nov 12,  2:44pm, wrstuden@nas.nasa.gov (Bill Studenmund) wrote:
-- Subject: re: emul/aout, compat/aout [was: Re: Upcoming releases]

| 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 prefer the idea of a separate subtree, because it is easier to clean-up.
But it does not really matter.

| 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..

I would just stat /path/aout and if it exists look only there. If it does
not, then look at /path, being careful about ELF files. Also have an
LD_WARN_AOUT option which when set to 1 warns about a.out binaries executed,
when set to 2 warns about libraries in a non-aout directory and when set
to 3 warns about both.

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

I meant having two builds for a.out

| Also, what about upgrading packages??

This is a complete lose. This is why the compat_aout is better in this case,
because you can move all your packages in /emul/aout, and start from scratch.
With compat_aout you can also have a version of the toolchain that produces
a.out binaries coexisting with your elf one.

The major problem with packages is that you cannot live in a mixed world;
if you upgrade parts to elf you will need to upgrade all dependent packages
and it is a big cascading effect. Moving the libs to pkg/lib/aout can help,
but there might be other .so files in other places [the XFree86 server
.so files are an example]. Does perl have .so files in funny places too?

christos

christos