From: antispam@fricas.org   
      
   Simon Clubley  wrote:   
   > On 2025-08-30, Waldek Hebisch  wrote:   
   >> Simon Clubley  wrote:   
   >>>   
   >>> That's where I gave up. I either didn't understand the required   
   >>> VMS-specific build steps or there were bits missing from the public   
   >>> source kits.   
   >>   
   >> There are missing pieces, build needs VMS header files and libraries.   
   >> If those pieces are incomplete, then configuration may go wrong   
   >> and lead to trobles later.   
   >>   
   >> Currently I have fairly incomplete set of header files, so I expect   
   >> trouble due to this.  OTOH libgcc seem to compile fine, so C   
   >> compiler probably will work.  I worked around trouble with   
   >> shared images by configuring gcc with '--disable-shared',   
   >> suboptimal but must do for now.   
   >>   
   >   
   > If you look at the links Arne posted, you will see I took across to   
   > Linux the VMS-supplied header files inc addition to the libraries.   
   > According to those notes, it appears I also had to write patches   
   > for those headers.   
   >   
   > When I talked about bits missing, I wasn't thinking about the headers   
   > and libraries. Given that Adacore didn't start using Newlib or something   
   > similar to support VMS, that was pretty much expected.   
   >   
   > I was thinking more about bits missing within the compiler or binutils   
   > itself, especially given the crashes I had with Fortran. I was wondering   
   > if, for example, there are bits missing in the image initialisation   
   > sequence, along with other similar types of missing bits.   
      
   I now got to C++ problem.  In fact, this may be binutils problem:   
   gcc generates an assember file and as from binutils-2.21 aborts on   
   this file.  as from current binutils developement tree produces   
   error message instead:   
      
   pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj array_type_info.s   
   array_type_info.s: Assembler messages:   
   array_type_info.s: Error: no entry symbol for global function '_   
   N10__cxxabiv117__array_type_infoD1Ev'   
      
   The offending function is defined in the following way:   
      
           .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
           _ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv1   
   7__array_type_infoD2Ev   
      
   If I delete this definition and the ony use of it the file assembles OK.   
   AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly   
   defined.   
      
   DEC assembler apparently uses different syntax, so I can not check   
   if the file is correct using DEC assembler.  But I guess that similar   
   equates work with DEC assembler, so probably handling of equates in   
   GNU as is faulty (possibly corresponding piece is missing).   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)