Great!
> How important do you think it is to duplicate how OSF/1 (DEC Unix) implements
> shared libraries? Is running OSF/1 shared executables really that important?
Linux already does run OSF/1 shared libraries, using the OSF/1
/sbin/loader program etc.
We don't really need to try to make linux shared libraries compatible
with the OSF/1 ones: as far as I know, nobody has good documentation on
the OSF/1 shared libraries, and I ended up doing the OSF/1 binary
compatibility by writing a special loader of my own and looking at what
OSF/1 put on the stack..
I wouldn't mind it if OSF/1 was able to run linux binaries (even shared
ones), but quite frankly, with the lack of documentation I don't really
see that as an option. Besides, some linux system calls still wouldn't
be supported under OSF/1 (linux' getdents() would be used by the shell
for filename expansion etc).
> How committed are you to the ECOFF executable format? Would you be adverse
> to adopting ELF so we can take advantage of the (apparently) simple to use
> shared library code that exists for ELF?
I'd suggest keeping to ECOFF (which is essentially a.out + small file
headers) until we know what the status of ELF is on the alpha. It would
be silly to have two different and incompatible ELF implementations
(anybody know if OSF/1 is defined now?).
How about just using the original Linux a.out-type shared libraries? The
only kernel thing you need to do is just to add the "uselib()" system
call to arch/alpha/kernel/entry.S (I actually did that now, so as of
1.3.31, the alpha will have "sys_uselib()" as system call #313).
The a.out fixed entry-points etc table building stuff is slightly
painful, and you'd need to port the changes made to the linux linker for
it (the "tools" directory of a linux GCC site, I do believe), but it
shouldn't be too bad. Knock wood. (I certainly have been too lazy to
even look into it to any great degree).
Linus