From: antispam@fricas.org   
      
   hb0815  wrote:   
   > On 9/18/25 2:55 AM, Waldek Hebisch wrote:   
   >   
   >>>> I have noticed that VMS linker inserts reference to 'LIB$INITIALIZE',   
   >>>> while with my fake libraries GNU linker does not reference this   
   >>>> function.   
   >>>   
   >>> The linker does not insert such a reference. If the LIB$INITIALIZE   
   >>> module is included in the image, then it was explicitly included or   
   >>> there was a reference to a symbol defined in this module from one of the   
   >>> to be linked object modules.   
   >>   
   >> Well, I tried:   
   >>   
   >> $ link CRT0.OBJ,CRTBEGIN.OBJ,HH.OBJ,crtend.obj,hh.opt/options /NOSYSLIB   
   >   
   > It gets hairy or confusing or both ...   
   >   
   > I assume the link was on VMS with object created with the binutils (on a   
   > non-VMS system). The 0 and BEGIN indicate that there is something that   
   > needs to be done at program start. (On my Linux system there is a   
   > crtbegin.o and that contains a section .init_array, the equivalent ELF   
   > section of the LIB$INITIALIZE PSECT.   
      
   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.   
      
   >> where hh.opt specifies linking with DECC$SHR.EXE and SYS$PUBLIC_VECTORS.EXE   
   >> and linker complains about C$_EXIT1 and LIB$INITIALIZE being undefined.   
   >> My object files have only 5 external references, 4 are resolved by   
   >> DECC$SHR.EXE.  C$_EXIT1 is referenced in CRT0.OBJ and defined by   
   >> something in STARLET.OLB, but since I do not include STARLET.OLB in   
   >> the link linker should complain.  But there is no reference to   
   >> LIB$INITIALIZE in the object files above.   
      
   Correction: there is a reference, but GNU linker does not mind   
   when it is not present (while with normal symbols GNU linker complains   
   loudly and refuses to create executable).   
      
   >  IIUC VMS shared libraries   
   >> are "fully linked", that is normally shared library should not cause   
   >> reference to some extra symbol.  But LIB$INITIALIZE apparently is   
   >> special.  When I skip shared libraries from the link I get information   
   >> about 5 unresolved symbols, so clearly referenct to LIB$INITIALIZE   
   >> is triggered by linking shared libraries.   
   >   
   > LIB$INITIALIZE is a "normal" PSECT (and symbol and module name - just to   
   > confuse ...). The PSECT contains the addresses of the functions to be   
   > called at init time. Referencing the symbol is just a common hack/trick   
   > to trigger inclusion of the module. The (user) code should do noting at   
   > all with whatever the symbol references.   
      
   There is some magic which creates reference to LIB$INITIALIZE.  Up to   
   now I did not find code responsible for this reference, so I wronly   
   thought that there are no reference.   
      
   > If you link on VMS, create a full map with cross references and you will   
   > see what references LIB$INITIALIZE. The current binutils ld can also   
   > create map files with references.   
   >   
   >> BTW: I included SYS$PUBLIC_VECTORS.EXE in the link because after   
   >> default linking executable references both DECC$SHR.EXE and   
   >> SYS$PUBLIC_VECTORS.EXE.  In particular executable uses slot   
   >> number 282 in symbol vector of SYS$PUBLIC_VECTORS.EXE.  This   
   >> slot does not correspond to any function from official list   
   >> of system services, so I suspected that this may be   
   >> LIB$INITIALIZE.  But apparently LIB$INITIALIZE is in STARLET.OLB   
   >> and uses some unknown system service.   
   >   
   > On Eisner, entry 282 in SYS$PUBLIC_VECTORS is SYS$NATIVE_TO_TRANSLATED.   
   > And yes, that's not an official system service.   
      
   Yes.  When I skipped SYS$PUBLIC_VECTORS.EXE from the link VMS   
   linker complained about missine SYS$IMGSTA, so for a moment   
   I thought that slot number 282 corresponds to SYS$IMGSTA.  But   
   testing shows that SYS$IMGSTA corresponds to slot 52 and   
   SYS$NATIVE_TO_TRANSLATED indeed corresponds to slot 282.   
      
   Now I do not think that this reference to SYS$NATIVE_TO_TRANSLATED   
   is important: it is probably only used when running translated VAX   
   code which is presumably quite rare.  OTOH calls to LIB$INITIALIZE   
   seem to be important part of program startup and finalization,   
   so I need to work out that.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)