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