From: johnrreagan@earthlink.net   
      
   On 9/5/2025 1:37 PM, 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   
   >> array_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__cxxabiv117__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.   
   >   
   > If you need an open source name shortener that mimics what the DEC   
   > compilers do, I've got one here:   
   >   
   >  vms_shorten_symbol.c>   
      
   On ELF-based systems, the linker doesn't care about symbol length   
   anymore.  You can easily have symbols with 1000s of characters   
   (including non-printing ones).  The librarian can handle longer names as   
   well, but you have to pick a max-length when creating the OLB.  The   
   default may not be large enough for you.  ANALYZE is ok with longer   
   lengths but we recently fixed a bug dumping out a symbol vector with   
   very long names in LIBCXX.  I think the debugger is ok, but you then   
   have to deal with command line length if you want to do a SET BREAK on a   
   very long C++ mangled name.   
      
   Only C/C++ have that checksum solution.  Other compilers, like Pascal,   
   won't let you go beyond 31.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)