Re: installworld crt1.o regression?

["c.turner" <c.turner@xxxxxxxxxxxxxxxxxxx>]

on closer inspection definately looks to be some elisp related cruft.. 

thanks! normally wouldn't have bothered on this list. 
just remembered the other crt thread which I couldn't find 
for reference - will submit a patch upstream sometime soon.

in any case, in case anyone is wondering:

(impending vi/emacs flame war disclaimer: I use both)

looks like the pre-crt0.c sets up a 'data_start' symbol in
front of crt0.o which explains the link order and borked target.
The symbol is then used various flavors of the 'unexec'
function/program, which is designed essentially to generate an object 
file from the running process.

this looks to be used to generate the initial emacs (temacs?)
which then interprets a bunch of elisp, and calls 'dump-emacs',
which says in the *Help*

---
dump-emacs is a built-in function.
(dump-emacs FILENAME SYMFILE)

Dump current state of Emacs into executable file FILENAME.
Take symbols from SYMFILE (presumably the file you executed to run
Emacs). This is used in the file `loadup.el' when building Emacs.

You must run Emacs in batch mode in order to dump it.
---

so.. some elisp interpreter trickery essentially - might
affect other non-gnu code generator type things, but probably
not worth the support. wondering if this will break my 
unsubmitted SBCL port.. hmm.. time for some tests.

On Wed, 31 Jan 2007 10:56:25 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> wrote:

> 
> :c.turner wrote:
> :> not sure what POSIX / etc. have to say about this, but if
> :> a 'crt' file isn't required, I'll submit against pkgsrc and / or
> :> upstream as per the usual procedure for pkgsrc errors.
> :
> :It is required to setup the C environment for the actual C program,
> for :any program basically. I don't know why it insists on having 
> :/usr/lib/crt1.o though.
> :
> :Cheers,
> :-- 
> :         Thomas E. Spanjaard
> :         tgen@netphreax.net
> 
>     No application build should ever specify crt1 manually.  I don't
>     know why temacs insists on doing so.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>