From: antispam@fricas.org   
      
   hb0815  wrote:   
   > On 9/16/25 21:24, Waldek Hebisch wrote:   
   >   
   >> I have made a simple-minded generator of fake shared libraries.   
   >> Using fake 'DECC$SHR.exe' containing just 5 real symbols (and   
   >> hundreds of dummies to fill unused positions in symbol vector)   
   >> I managed to link on Linux a simple "Hello from VMS" program   
   >> and the program run correctly on VMS.   
   >>   
   >> I still have a problem: ATM I do not know how access to variables in   
   >> shared images works.  So I have bogus reference to 'C$_EXIT1'.   
   >   
   > I don't see C$_EXIT1 in DECC$SHR on Alpha (Eisner, V8.4-2L2).   
   >   
   > C$_ are message codes, for example C$_ENOENT (%C-F-ENOENT, no such file   
   > or directory). That is integer literals.   
   >   
   > Read/write data symbols are as procedure symbols with EGSY$V_NORM clear.   
   > Literals symbols are as data with EGSY$V_REL clear.   
   >   
   > Create a small shareable image on VMS/Alpha with a procedure, data and   
   > an integer literal and you will see the flags and the differences in the   
   > values. With analyze/image or a full map you should be able to find the   
   > symbol vector in dump's output.   
      
   Thanks, GNU startup file declares C$_EXIT1 as:   
      
   extern int C$_EXIT1;   
      
   but later uses only address of it.  I guess it is how one can access   
   VMS literals from C.  I am not sure why they are doing it this way,   
   they just hardcode a buch of constants, but apparently want to   
   reference symbol in this case.   
      
   I worked out how to find symbol vector.  GNU header files have   
   definitions of various constants so I think I know how to set   
   up entry for a constant.   
      
   >> 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   
      
   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.   
      
   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.   
      
   BTW2: GNU linker has special logic which under same conditions   
   (which I am trying to understand) will include LIB$INITIALIZE   
   in the link.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)