home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,366 of 264,096   
   hb0815 to Waldek Hebisch   
   Re: Unix stat on VMS   
   18 Sep 25 15:58:00   
   
   From: mw40171@mucweb.de   
      
   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.   
      
   > 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.  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.   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca