> > False. As I said, I have systems that read a.out format object files > > and they would need to be ported to read ELF object files instead.
> > Furthermore, they write themselves out (after loading object files) in > > a.out format, and would need to be ported to write themselves out > > in ELF format. > Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer "yes, we've considered this and decided that the overhead of supporting it is to much", but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the "modern" alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message