Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!network!sdcsvax!ucsdhub!hp-sdd!hp-pcd!hplabs!hpfcdc!marc
From: marc@hpfcdc.HP.COM (Marc[e] Sabatella)
Newsgroups: comp.sys.hp
Subject: Re: making Gnu Emacs on HP9000/340
Message-ID: <5570277@hpfcdc.HP.COM>
Date: 24 Aug 89 15:23:59 GMT
References: <722@eecae.ee.msu.edu>
Organization: HP Ft. Collins, Co.
Lines: 29

>These things are variables and constants that are defined in a new C
>run-time file that I think is called "end.o" or something, but I have
>really forgotten now.  In any case, lacking the source to the HP C runtime
>start up files, I looked at the object code with a debugger, and eventually
>created the following file, which I called "hack.s":

Actually, they are in crt0.o
I don't think supplying source would help all that much - the mapping from
assembly source to object file is pretty much one-to-one anyhow, so the
debugger disassembly would be just as good.

In any case, rather than always picking on HP for our "non-standard" crt0,
it would be much more profitable to pick on Stallman et al for their incredible
stupidity in trying to redefine crt0.  There is nothing OS-independent you can
do there that you couldn't have done in main(), and all the standards texts are
pretty clear on the point that the run time code belongs to the implementor.
Why does GNU persist in this inherently non-portable practice?

Another example would be Sun's crt0.o, which includes support for shared
libraries and dynamic loading/linking.  Does GNU supply a Sun-specific crt0,
or do they tell you to compile with archive libraries?  We will undoubtedly
run into the same thing when HP-UX supports shared libraries.  Of course, if
you use GCC and the GNU libraries, you aren't going to get shared libraries
anyhow, but then again, you won't need the implementor's crt0.

--------------
Marc Sabatella
HP Colorado Language Lab
marc%hpfcrt@hplabs.hp.com