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

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

Reply via email to