From: johnrreagan@earthlink.net   
      
   On 3/24/2025 2:41 PM, Simon Clubley wrote:   
   > On 2025-03-23, Arne Vajhøj  wrote:   
   >>   
   >> But VMS LLVM is rather old (if I remember correctly then it   
   >> is, because it had to be build on Itanium with VMS C++   
   >> for cross compilers).   
   >>   
   >   
   > You also need CMake to build current LLVM versions. John was working   
   > on this at one time, but I don't know what the current status is.   
   >   
   > Simon.   
   >   
   Lots of good questions for sure!  And be sure to come see me in person   
   in May in Malmö at the VSI Bootcamp.  I'll be on display daily.   
      
   Yes, we are currently using clang/LLVM 10.0.1.  It is bootstrapped using   
   a Linux version of the same code base with changes to create OpenVMS   
   objects (it knows about CRTL name mapping, argcounts, and all that   
   stuff).  What we did was:   
      
   - start with the plain 10.0.1 sources and 10.0.1 binaries   
   - add code to clang/LLVM (much of the LLVM changes were just carried   
   over from the LLVM 3.4.2 codebase we used with the cross compilers)   
   - build that code on Linux creating a 10.0.1v compiler   
   - use that compiler to build it all again   
   - copy all the .o files over to an OpenVMS machine to put into OLBs   
   - link clang using those OLBs on OpenVMS   
   - use that clang on OpenVMS to build our G2L (GEM to LLVM converter)   
   - link all the legacy frontends (originally build with cross compilers   
   but now built with native compilers) with the G2L and LLVM libraries   
   - test & make kits   
   - and Bob's your uncle and much easier than learning to say the French R   
   sound   
      
   As for native building, we do have a CMake ported and are currently   
   working on native building that 10.0.1v source tree on OpenVMS V9.2-3   
   including some work to CMake to make it easier for symbol vector   
   management for LIBCXX/LIBCXXABI.  Not quite to testing yet.   
      
   We have also downloaded the latest LLVM (either 20.1.0 or 20.1.1, I'd   
   have to go check).  As a first step, we've been able to compile that on   
   Linux using the same 10.0.1v compiler that we use today.  The LLVM 20   
   code base is much larger as you can imagine and we're working on linking   
   up the LIBCXX/LIBCXXABI libraries right now.  The number of LLVM   
   libraries is also different.  We've merged in some but not all of the   
   OpenVMS additions but nothing tested yet.  We'll have to upgrade our G2L   
   since the internal LLVM IR is not guaranteed to be upward compatible and   
   they've changed several of the interfaces over the last few years.  And   
   to make it even more painful, LLVM 20 now requires a newer CMake version   
   than the one we ported.  Ugh!  We'll do it again and then look at   
   providing it online as well.   
      
   As for merging our code back into the actually LLVM repo, that's still a   
   work in progress.  Once we switch to LLVM 20, we will be in a much   
   better position to make the case to the LLVM community.  I think it will   
   be an easier discussion for the LLVM changes.  The clang changes might   
   be a tougher sell since our addition of dual-sized pointers, listing   
   files, etc might scare off a few people. It would be difficult for the   
   build bots to build (we would have to provide and manage some systems).   
      
   Making our VSI git repositories visible would be another choice.   
   However, if you haven't noticed,   
      
   https://arstechnica.com/gadgets/2025/03/google-makes-android-dev   
   lopment-private-will-continue-open-source-releases/   
      
   Besides the sources (and scripts), I'd like to make another kit of   
   pre-built images (and perhaps the LLVM libraries) that come out of the   
   LLVM build today.  There are some of the LLVM tools that are only useful   
   to compiler developers like llvm-dis but there are some tools like   
   clang-format, llvm-objdump, llvm-dwarfdump, llvm-nm, etc that others   
   might want.  For example, the X86ASM product on the support portal is   
   just the llvm-mc tool.  llvm-mc is quite powerful as both an assembler   
   AND disassembler.  It can even convert between AMD and Intel syntax as a   
   party trick.   
      
   G2L, while completely written by VSI, would only be useful if you have a   
   compiler frontend that generates GEM CIL.  And G2L does use GEM headers   
   so that's where the existing HPE copyrights start to appear.   
      
   Vi ses snart i Malmö   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)