On Tue, Sep 03, 2002 at 11:32:22PM +0100, Richard Tobin wrote:
> > > 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
actually with as(1), because gcc is only generates assembler file,
which is then translated into the object file by assembler (as).
Assembler by itself is part of binutils, not a compiler suite.
> 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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message