Date: Wed, 4 Sep 2002 01:40:13 +0300 From: Maxim Sobolev <sobomax@FreeBSD.ORG> To: Richard Tobin <richard@cogsci.ed.ac.uk> Cc: Juli Mallett <jmallett@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, current@FreeBSD.ORG Subject: Re: aout support broken in gcc3 Message-ID: <20020903224013.GE9384@vega.vega.com> In-Reply-To: <200209032232.XAA04151@rhymer.cogsci.ed.ac.uk> References: <200209032232.XAA04151@rhymer.cogsci.ed.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Maxim > 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 majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020903224013.GE9384>