From: antispam@fricas.org   
      
   Craig A. Berry  wrote:   
   >   
   > On 9/5/25 6:55 AM, Waldek Hebisch wrote:   
   >   
   >> 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 a   
   ray_type_info.s   
   >> array_type_info.s: Assembler messages:   
   >> array_type_info.s: Error: no entry symbol for global function   
   '_ZN10__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__cxxa   
   iv117__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.   
   >   
   > Note that this symbol is 38 characters long.  The native VMS toolchain   
   > traditionally limits itself to 31-character symbols and uses a checksum   
   > to shorten symbols that are longer.  The linker, the librarian, and the   
   > inertia of existing code are all things I've heard blamed for this state   
   > of affairs.   
   >   
   > I have no idea whether the tools you are using require or are capable of   
   > observing the 31-character limit.  If some parts do and other parts   
   > don't, that could obviously cause trouble, and of course you've got the   
   > C++ name mangler in the mix as well.   
      
   IIUC GNU assembler internaly uses arbitrarily long names (in dynamically   
   allocated buffers) and shortens names only on output.  Anyway, I   
   tried shorthening names in the input file and it makes no difference.   
      
   All indicates that GNU assembler can not handle simple symbol   
   equality as intended.  Namely relevant part of original code   
   including definitions of _ZN10__cxxabiv117__array_type_infoD2Ev   
   and _ZN10__cxxabiv117__array_type_infoD1Ev is:   
      
           .link   
           .align 3   
   _ZN10__cxxabiv117__array_type_infoD2Ev:   
           .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
   $80.._ZNSt9type_infoD2Ev..lk:   
           .linkage _ZNSt9type_infoD2Ev   
           .end _ZN10__cxxabiv117__array_type_infoD2Ev   
           .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
           _ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv1   
   7__array_type_infoD2Ev   
      
   The intent is clearly that _ZN10__cxxabiv117__array_type_infoD1Ev   
   should be alternative name for _ZN10__cxxabiv117__array_type_infoD2Ev,   
   but for some reasons assembler can not handle this.  AFAICS GNU   
   assembler for VMS believes that that given function should have   
   only one name.  For example I tried to transform fragment above   
   to:   
      
           .link   
           .align 3   
   _ZN10__cxxabiv117__array_type_infoD2Ev:   
           .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
   $80.._ZNSt9type_infoD2Ev..lk:   
           .linkage _ZNSt9type_infoD2Ev   
           .end _ZN10__cxxabiv117__array_type_infoD2Ev   
           .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
           .ent _ZN10__cxxabiv117__array_type_infoD1Ev   
   _ZN10__cxxabiv117__array_type_infoD1Ev:   
           .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
           .linkage _ZNSt9type_infoD2Ev   
           .end _ZN10__cxxabiv117__array_type_infoD2Ev   
      
   that is I actually build second descriptor duplicating content of   
   descriptor for _ZN10__cxxabiv117__array_type_infoD2Ev and GNU   
   assembler still does not want to accept this.  More precisely,   
   version  2.21 gives the same error message as original code,   
   current trunk says:   
      
   at3.s: Assembler messages:   
   at3.s:55: Fatal error: .pdesc doesn't match with last .ent   
      
   I do not know if VMS object format allows alternative names,   
   that is two symbols resolving to the same name (but I also   
   am not aware of any reason for such restriction), but even   
   if there were such restriction version with duplicate descriptor   
   should work around this.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)