x86_64 C++ regression (UDFSYM) between Build dates 07-31-2023 and 11-28-2023?

[sms]

Code: Select all

   Source kit:

      http://antinode.info/ftp/unrar/unrar-5_9_4a_vms/unrar-5_9_4a_src.zip

   My notes say that this all worked on VMS V9.2-1 with an older
compiler: clang version 10.0.1 (Build date: 07-31-2023).  It still works
on IA64 VMS V8.4-2L3 with VSI C++ V7.4-006.

   Now, on VMS V9.2-2, with CXX Build date: 11-28-2023 or VSI C++
V10.1-1 (Build date: 01-10-2024), the LINK fails:

%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM,        ERRHANDLER 
%ILINK-W-USEUNDEF, undefined symbol ERRHANDLER referenced
[...]

   Possibly relevant:

      The compiles are done with "/names = uppercase".
      The consumers all refer to "ErrHandler".
      global.hpp should say: extern ErrorHandler ErrHandler;
      /LIST does less than I'd've hoped.  I haven't tried "-E".

   My C++ expertise is (still) nil, so I don't follow it closely, and I
don't know if anything similar has been reported already.

   I was looking at a newer UnRAR version (6.1.7) when I hit this.  Not
the newest version (7.0.7), as newer ones seem to employ C++ 11
features.

[joukj]

The version I have I extracted from github in 2019.

>global.hpp should say: extern ErrorHandler ErrHandler;

on my machine global.hpp says : EXTVAR ErrorHandler ErrHandler;
If You look into the code EXTVAR is almost always defined as extern except when compiling global.cpp, where it is "blank". So global.obj should contain the definition.

[sms]

Code: Select all

> The version I have I extracted from github in 2019.

   For an actual version, look at version.hpp, or:

      pipe [run] unrar | search sys$pipe Copyright

> on my machine global.hpp says : EXTVAR ErrorHandler ErrHandler; [...]

   Right.  Lazy brain here.

   The useful (and, I believe, accurate) info was that this stuff works
on IA64 (and Alpha), and _did_ work on x86_64 with the early compiler.

[joukj]

> I was looking at a newer UnRAR version (6.1.7) when I hit this. Not
>the newest version (7.0.7), as newer ones seem to employ C++ 11
>features.

You also could try this new version on x86_64, since there you can use cxx/stan=cxx11 or cxx/stan=gnu11.
My port of a recent version of poppler dor x86_64 even depends on a more recent c++ standard and works.

[sms]

Code: Select all

   Ah.  Thanks.  I normally think of /STANDARD as a dumb-down option for
the C compiler (VAXC), not a smarten-up option for anything.

   Yes, with a command like:
      mms /des=[.vms] /macro = "CXXOPTS=/STANDARD=CXX11"
the latest-version (7.0.7) build (on x86_64) works as expected.  Right
up until the (same) LINK failure, that is.


   Naturally, the new Community VMDK has the same, stale compiler:

$ show syst /noproc
OpenVMS V9.2-2  on node V922    5-APR-2024 12:39:16.13   Uptime  0 00:11:15

$ cxx /vers
VSI C++ V10.1-1
clang version 10.0.1 (git@bitbucket.org:vms_software/llvm-10.0.1.git f8c06aa3b94
6de6956aade907a641da216dbe1fd)
Build date: 01-10-2024
Target: x86_64-OpenVMS
Thread model: posix
InstalledDir: V922$DKA300:[SYS0.SYSCOMMON.][SYSEXE]

   Perhaps next year (in Jerusalem?)...


      [...] The level of participation in activities such as
      contributing open-source software, creating wiki articles, and
      providing assistance on forums has not matched the scale of the
      program. [...]

   It's a mystery.