From: antispam@fricas.org   
      
   hb0815  wrote:   
   > On 9/29/25 18:17, Waldek Hebisch wrote:   
   >   
   >> Now about troubles.  VMS C functions use different name at C level   
   >> and different in libraries.  Moreover, while offically function is   
   >> available in "imagelib.olb", actual function is in a different library   
   >> and this library is needed for succesful linking.  So, one needs   
   >> to know real name of a given function and teach gcc to use it.   
   >   
   > Yes, for example, printf in the source code is changed  to DECC$GXPRINTF   
   > in the object module. DECC$GXPRINTF is a symbol in the shareable image   
   > library IMAGELIB.OLB. Symbols in a library must be unique. That explains   
   > the DECC$ prefix. I don't know what the GX means or where it comes from.   
      
   gcc renames printf to decc$tprintf.  IIUC leading t means printf   
   working with T format floats, that is with IEEE floats.  G means   
   (new ???) VAX floating point format, X means 128-bit long double   
   format, so GX prefix may mean using G format doubles and X format   
   long doubles.  gcc by default uses 64-bit long double, when I   
   request 128-bit long double then gcc renames printf to decc$txprintf.   
      
   BTW: I do not know why, but gcc emits names of functions in DECC$SHR.EXE   
   in lower case, while math library functions in upper case.   
      
   > I also don't know where the mapping/replacement table is.   
      
   gcc has file (starting from root of gcc source tree)   
   gcc/config/vms/vms-crtlmap.map.  This file contains list of remaped   
   functions and flags giving rules for remaping.  Those remapings   
   are under control of compiler command line, chosing 64 bit pointers   
   causes remaping to 64 bit version of the function.  Similarly, there   
   are variants for different floating point formats.   
      
   > IMAGELIB.OLB contains only the symbol and a link to the shareable image.   
   > The actual code (and data) is in the shareable image, not in a library.   
      
   Yes.   
      
   > So if you link using IMAGELIB.OLB you link with DECC$SHR. At least on   
   > Alpha, the symbol DECC$GXPRINTF is also in STARLET.OLB. By default this   
   > OLB is not used, by default you dynamically link and not statically.   
      
   GNU linker always uses both IMAGELIB.OLB and STARLET.OLB, in that   
   order.  If symbol is found via IMAGELIB.OLB linker will not use   
   corresponding symbol from STARLET.OLB, even if present.  VMS   
   documentation says that default action is the same, but options can   
   exclude IMAGELIB.OLB or both IMAGELIB.OLB and STARLET.OLB.   
      
   In fact, some symbols like C$_EXIT1 and LIB$INITIALIZE seem to come from   
   STARLET.OLB, even when other symbols come from shared images.   
      
   > Do   
   > a link on VMS/Alpha with a map file. In the map you will only see   
   > DECC$SHR, no STARLET.OLB and no IMAGELIB.OLB.   
      
   Yes.  I mostly looked at executables as I wanted to see information not   
   present in map file, but the result is equivalnet.  IIUC STARLET.OLB will   
   never show up, debug symbols may point to specific object files but   
   not to static library.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)