From: mw40171@mucweb.de   
      
   > CRT0.OBJ, CRTBEGIN.OBJ and CRTEND.OBJ are "standard" gcc files.   
   > Sources are included in gcc tarball, but are a bit hairy due to   
   > multiple conditionals.   
   >   
   > Point is that using GNU linker those file just require 5 symbols:   
   > main, decc$main, decc$malloc, decc$atexit and C$_EXIT1.  main is   
   > provided by HH.OBJ and in turn needs decc$puts.  Using   
   > GHU linker on Linux and a fake library exportingh the 5 symbols   
   > above those files links fine and resulting executable runs on   
   > VMS.  CRTBEGIN.OBJ and crtend.obj contain reference to   
   > LIB$INITIALIZE.  But somewhat GNU linker treats it as "weak"   
   > reference and does not complain that LIB$INITIALIZE is absent.   
   > Apparently VMS linker insists on its presence.   
   >   
   > AFAIK CRTBEGIN.OBJ is responsible for program initialization, in   
   > particular for running things marked as 'constructors'.  CRTEND.OBJ   
   > is resposible for finalization.   
      
   A simplified view of the call flow: If there is an entry for init code   
   in the image transfer array, then some code runs before the before the   
   main program code runs. The entry points to code in the image. This code   
   walks through the code entries in the init section and calls them. Once   
   this code returns, the main entry of the program is called.   
      
   The linker sets up the transfer array. On VMS the linker creates an   
   entry for init code, when it sees/processes the LIB$INITIALIZE module.   
   This module is (only) in STARLET.OLB.   
      
   The LIB$INITIALIZE module brings in the code to walk the init section.   
      
   By default, the C compiler on VMS does not set up any image init code.   
   It seems that the GNU C compiler always requires and sets up image init   
   code.   
      
   Since all the magic is in the linkers and the fact that a simple program   
   linked with the GNU linker works on VMS, it seems that the GNU linker   
   has its own code to walk the init section. Only on VMS the GNU linker   
   can have access to the LIB$INITIALIZE module from STARLET.OLB. So the   
   code address in the init transfer entry seems to point to GNU generated   
   code.   
      
   It also seems that that the object module generated by GNU can be linked   
   on VMS. For this to work the LIB$INITIALIZE module needs to be included.   
   As said before, this is often done by referencing the symbol   
   LIB$INITIALIZE. It seems on VMS, for GNU objects you always have to   
   include the LIB$INITIALIZE module from STARLET.OLB. With the default   
   /SYSLIB or by explicitly including the module.   
      
   I don't know how the GNU linker resolves LIB$INITIALIZE. Without having   
   access to the GNU object files I can only speculate. It's unlikely that   
   one of the modules defines the symbol. This could create multiple   
   defined symbols when linking on VMS and/or it could be that the VMS   
   linker can not set up the init entry in the transfer array because the   
   symbol is already resolved from a GNU object module. It's more likely   
   that the GNU linker handles the LIB$INITIALIZE symbol specially.   
      
   Again, I'm only guessing what the GNU linker does.   
      
   The linker maps should help to understand what's going on.   
      
   Also, on VMS there is no LIB$FINALIZE. So the GNU linker very likely   
   sets up some init code to establish an exit handler to run finalization   
   code.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)