notes.txt

--------------------------------------------------------------------------------
Microsoft Visual Studio - creation of the oorexx_builder project
--------------------------------------------------------------------------------

This section describes how to create a Visual Studio project named "oorexx_builder",
driven by the variables
$(builder_build_dir)
$(buildet_delivery_dir)

The oorexx_builder project can be used from any cmd where the builder has been
initialized, and the build command "ninja install" or "nmake install" is supported:
- ooRexx release
- ooRexx debug
- Executor release
- Executor debug
- Executor5 release
- Executor5 debug
- Executor5-bulk release
- Executor5-bulk debug

It's important to launch Visual Studio from the cmd where the builder has been run.
The builder creates environment variables that become visible from VS thanks to the /useenv option.
The directory from where you launch VS is not important.

devenv /useenv


------------------------------------
INSTRUCTIONS TO CREATE A NEW PROJECT
------------------------------------

-- Create the "oorexx_builder" project.

    File / New / Project
    Select Makefile project

    Click Next

    Project name = oorexx_builder

    Click Create

    Debug settings
    Leave the fields blank

    Click Next

    Release settings
    Keep same as debug configuration

    Click Finish

-- Define the "Build" and "No build" configurations.
-- The "Release" and "Debug" configurations are irrelevant, as you already made
-- this choice when initializing the builder in your command prompt.

-- You have also selected the platform, but it is not possible to rename platforms
-- in Visual Studio. Therefore, we will not modify them, but please note that they
-- will have no effect on the build.

    File / Configuration Manager

    In Active solution configuration, click <Edit…>
    Rename "Debug" into "Build"
    Rename "Release" into "No build"
    Click Close

    In Project contexts, click <Edit…> in the Configuration column
    Rename "Debug" into "Build"
    Rename "Release" into "No build"
    Click Close

    Close the configuration manager

-- Make the builder variables usable in the form $(builder...) from Visual Studio.

    Right-click on the "oorexx_builder" project (under solution) and select Open Folder in File Explorer
    Create the "builder.props" file in the project directoy ("C:\Users\jlfaucher\source\repos\oorexx_builder\oorexx_builder\builder.props").
    Copy-paste in builder.props:
    <Project>
      <PropertyGroup>
        <builder_delivery_dir>$(builder_delivery_dir)</builder_delivery_dir>
        <builder_build_dir>$(builder_build_dir)</builder_build_dir>
        <builder_build_command>$(builder_build_command)</builder_build_command>
      </PropertyGroup>
    </Project>

    Right-click on the "oorexx_builder" project and select Unload Project
    Right-click on the "oorexx_builder" project and select Edit Project File
    Add at the end, before the last tag:
    <Import Project="builder.props" />

    Save

    Right-click on the "oorexx_builder" project and select Reload Project

-- Define the build commands
-- To avoid the warning MSB8005: The property 'NMakeBuildCommandLine' is not defined,
-- all the combinations Configuration x Platform must be covered.

    Right-click on the "oorexx_builder" project and select Properties
    Select the "All Configurations" configuration
    Select the "All Platforms" configuration
        General
            Output Directory = $(builder_delivery_dir)\
            Intermediate Directory = $(builder_build_dir)\VisualStudio\
        NMake
            Build Command Line = REM no build for this configuration
            Rebuild All Command Line = REM no build for this configuration
            Clean Command Line = REM no build for this configuration
            Compile File Command Line = REM no build for this configuration
            Output = $(builder_delivery_dir)\rexx.exe
    Select the "Build" configuration
    Keep "All Platforms" selected
        NMake
            Build Command Line = cd /d %builder_build_dir% && %builder_build_command% install
            Rebuild All Command Line = cd /d %builder_build_dir% && %builder_build_command% clean install
            Clean Command Line = cd /d %builder_build_dir% && %builder_build_command% clean
            Compile File Command Line = REM no build for this configuration
            Output = $(builder_delivery_dir)\rexx.exe

    Click Ok

    Save the project


---------------------
INSTRUCTIONS TO BUILD
---------------------

    You switch configurations using the toolbar dropdown

    Select the "No build" config
    Build /  Build Solution (or Ctrl+Shift+B)
    Nothing is built

    Select the "Build" config
    Build /  Build Solution (or Ctrl+Shift+B)
    The build is launched


--------------------
INSTRUCTION TO DEBUG
--------------------

    Right-click on the "oorexx_builder" project and select Properties
    Select the "All Configurations" configuration
    Select the "All Platforms" configuration
        Debugging
            Command = $(builder_delivery_dir)\rexx.exe
            Command Arguments = -e "say hi; pull"
            working directory = what you need


    Click Ok

    You switch configurations using the toolbar dropdown

    Select either the "Build" or "No build" configuration
    With "Build", a build is always launched when you start debugging.
    With "No build", the debug is immediate.

    Debug / Start debugging
    (or F5)


--------------------------------------------------------------------------------
Windows WSL: Creation of the build environment
--------------------------------------------------------------------------------

# This procedure follows the ooRexx directory hierarchy described in build-oorexx.txt.
# It's not the best choice in terms of speed (requires 17 min for a full build),
# but the best choice for using the same source files from any environment.

# The ooRexx sources are available on the Y: drive
# (network drive mapped on a macOS directory)
sudo mkdir /mnt/y
sudo mount -t drvfs Y: /mnt/y

# The macos HOME directory is available on the Z: drive
sudo mkdir /mnt/z
sudo mount -t drvfs Z: /mnt/z

sudo mkdir /local
sudo ln -s /mnt/y/local/rexx /local/rexx
sudo ln -s /mnt/c/jlf/local/rexxlocal /local/rexxlocal

# /etc/wsl.conf, add:
[automount]
mountFsTab=true

# /etc/fstab add (use tabs):
Y:	/mnt/y	drvfs	defaults	0	0
Z:	/mnt/z	drvfs	defaults	0	0


# How to install a RECENT version of clang
https://official-stockfish.github.io/docs/fishtest-wiki/Advanced-Topics.html
cd ~/tmp
wget https://apt.llvm.org/llvm.sh
sudo bash llvm.sh
# In the next line, replace 19 by the installed version (four occurrences to replace)
sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-19 19 --slave /usr/bin/clang++ clang++ /usr/bin/clang++-19 --slave /usr/bin/llvm-profdata llvm-profdata /usr/bin/llvm-profdata-19


# See build-oorexx.txt for the build procedure.


--------------------------------------------------------------------------------
Details of the commands executed by make
--------------------------------------------------------------------------------

make VERBOSE=1 install

Remember: did not find how to select the right directory for build.
So I hardcoded this command in the Visual Studio solution of type nmake:
    e:
    cd E:\Local\rexxlocal\oorexx\build\executor.master\sandbox\jlf\trunk\windows-x86_64\cl\debug\build
    nmake VERBOSE=1 install


How to display the response files
https://stackoverflow.com/questions/57358039/how-to-see-the-underlying-compiler-linker-command-line-with-cmake-nmake
nmake has an option to display inline files / response files:
    /U Dump inline files
For recursive make you might want to set this in an environment variable like this:
    set MAKEFLAGS=U
This way, the content of all response files will appear on the console.
---
From cmd:
set MAKEFLAGS=U
devenv /useenv
nmake VERBOSE=1 install


--------------------------------------------------------------------------------
Creating a distribution
--------------------------------------------------------------------------------

From P.O.:
svn update
pkill rxapi
dnf -y -v remove ooRexx
rm -dfr ~/workspace/oorexx-centos8-build/oorexxbuild/
cmake -DBUILD_RPM=1 -DOS_DIST=centos8 -DCMAKE_BUILD_TYPE=RELEASE ../oorexxSVN
make clean
make
cpack ./
dnf -y -v install ~/workspace/oorexx-centos8-build/oorexxbuild/.rpm


--------------------------------------------------------------------------------
Creating a dmg for M1 Mac
--------------------------------------------------------------------------------

From P.O.:
On Jenkins we build everything starting from ~workspace, here are the steps for M1 Mac

# make ooRexx

# Stop and delete existing installation, leave no witnesses
pkill rxapi || true
rm -dfr ~/Applications/ooRexx5

# Clean the build dir to be sure everything is built fresh
rm -dfr oorexxBuild/*

mkdir -p oorexxBuild
cd oorexxBuild

# Installing to ~/Applications
/opt/homebrew/bin/cmake -G "Unix Makefiles" -DBUILD_OSX_UNIVERSAL_BINARIES=1 -DBUILD_DMG=1 -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=~/Applications/ooRexx5 ../oorexxSVN

make clean              # make sure rexx picks up the current build date
make

# install to ~/Applications/ooRexx5 (the installer build uses this so do not change)
make install

# now build the installer with a script generated by CMake
bash ./build_macOS_dmg.sh

The last step in the build chain generates a dmg drag&drop installer that can be used elsewhere.


--------------------------------------------------------------------------------
Technical infos
--------------------------------------------------------------------------------

MacOs File sharing (System preferences/sharing/File sharing)
The name jlfaucher.local is defined in this screen.
Can be modified (button Edit under the field Computer name)


MacOs NFS share
---------------
MacOs /etc/exports
/local              -mapall=502          where 502 is the uid displayed by the command id.
/Users/jlfaucher    -mapall=502

Linux fstab:
jlfaucher.local:/local	            /host/local	nfs	defaults	0	0
jlfaucher.local:/Users/jlfaucher    /host/local nfs defaults    0   0

MacOs SMB share
---------------
MacOs: menu System Preferences, then Sharing
Options: activate SMB, deactivate AFP
Activate file sharing and add /Local1 to the list

Windows SMB client
------------------
(replace Y: by your letter drive)
(replace Z: by your letter drive)

net use
 Y:        \\jlfaucher.local\Local1         Microsoft Windows Network
 Z:        \\vmware-host\Shared Folders     VMware Shared Folders

Must mount Local1 (exported by MacOs - System preferences/sharing/File sharing)
which contains this symbolic link to have
the directory 'Local' under Y:
/Local
/Local1
    Local@ -> /Local

http://superuser.com/questions/555715/mac-os-x-10-8-configure-smbd-to-follow-symbolic-links
Adding no-symlinks as a program argument in smbd's launchdaemon plist did the trick.
The file sharing services do need a restart after changing the file.
/System/Library/LaunchDaemons/com.apple.smbd.plist
<array>
        <string>/usr/sbin/smbd</string>
        <string>-no-symlinks</string>
</array>
[No longer works after upgrade to El-Capitan]
This change has been overwritten when upgrading to El-Capitan.
No longer possible to edit the file smbd.plist because of System Integrity Protection.
I follow a procedure described in https://forums.developer.apple.com/thread/17944:
sudo defaults write /Library/Preferences/com.apple.smbd.plist ProgramArguments -array-add -no-symlinks
Does not work...
Fallback:
sudo cp /System/Library/LaunchDaemons/com.apple.smbd.plist /Library/LaunchDaemons/jlf.smbd.plist
sudo chown root /Library/LaunchDaemons/jlf.smbd.plist
edit jlf.smbd.plist:
- re-apply the change described above
- change the label com.apple.smbd to jlf.smbd (2 occurences)
to do the first time, and to redo after each reboot:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.smbd.plist
sudo launchctl unload /Library/LaunchDaemons/jlf.smbd.plist
sudo launchctl load -w /Library/LaunchDaemons/jlf.smbd.plist


--------------------------------------------------------------------------------
Old build system: autoconf - automake
--------------------------------------------------------------------------------

https://stackoverflow.com/questions/2531827/what-are-makefile-am-and-makefile-in

DEVELOPER runs these:

1) autoconf - creates shippable configure script (which the installer will run to make the Makefile)
    configure.in -> autoconf -> configure (script) <---- Note! configure.in is depreciated.
    configure.ac -> autoconf -> configure (script) <---- Now use configure.ac / (*.ac = autoconf)
2) automake - creates shippable Makefile.in (which configure will later read to make the Makefile)
    Makefile.am -> automake -> Makefile.in / (*.am = automake)

INSTALLER runs these:

1) ./configure - creates the Makefile (from Makefile.in).
    Makefile.in -> configure -> Makefile (*.in = input file)
2) make - creates the application (from the Makefile just created).
3) sudo make install - installs the application

--------------------------------------------------------------------------------
Architectures
--------------------------------------------------------------------------------

Should I use aarch64 instead of arm64?

https://stackoverflow.com/questions/31851611/differences-between-arm64-and-aarch64
"AArch64" and "ARM64" are different names for the same thing.
But... read all the answers, it seems the only official name is "AArch64".

https://devblogs.microsoft.com/oldnewthing/20220726-00/?p=106898
The 64-bit version of the ARM architecture is formally known as AArch64.
It is the 64-bit version of classic 32-bit ARM, which has been retroactively renamed AArch32.
Even though the architecture formally goes by the name AArch64, many people
(including Windows) call it arm64.

https://en.wikipedia.org/wiki/AArch64
AArch64 or ARM64 is the 64-bit extension of the ARM architecture family
24 occurences of the word "AArch64".
1 occurence of the word "ARM64"

https://memgraph.com/blog/ship-it-on-arm64-or-is-it-aarch64
We found that usually, the Debian packages have an arm64 suffix
while RPM has an aarch64 suffix.
Therefore we are using x86_64 and aarch64 suffix for our RPM packages,
and amd64 and arm64 for our Debian packages.
And the good thing is that Docker follows the same convention


llc --version
LLVM (http://llvm.org/):
  LLVM version 15.0.6
  Optimized build.
  Default target: arm64-apple-darwin21.6.0
  Host CPU: apple-m1

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    avr        - Atmel AVR Microcontroller
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    ve         - VE
    wasm32     - WebAssembly 32-bit
    wasm64     - WebAssembly 64-bit
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore


rustc --print target-list
    aarch64-apple-darwin
    aarch64-apple-ios
    aarch64-apple-ios-macabi
    aarch64-apple-ios-sim
    aarch64-apple-tvos
    aarch64-apple-watchos-sim
    aarch64-fuchsia
    aarch64-kmc-solid_asp3
    aarch64-linux-android
    aarch64-nintendo-switch-freestanding
    aarch64-pc-windows-gnullvm
    aarch64-pc-windows-msvc
    aarch64-unknown-freebsd
    aarch64-unknown-hermit
    aarch64-unknown-linux-gnu
    aarch64-unknown-linux-gnu_ilp32
    aarch64-unknown-linux-musl
    aarch64-unknown-netbsd
    aarch64-unknown-none
    aarch64-unknown-none-softfloat
    aarch64-unknown-openbsd
    aarch64-unknown-redox
    aarch64-unknown-uefi
    aarch64-uwp-windows-msvc
    aarch64-wrs-vxworks
    aarch64_be-unknown-linux-gnu
    aarch64_be-unknown-linux-gnu_ilp32
    arm-linux-androideabi
    arm-unknown-linux-gnueabi
    arm-unknown-linux-gnueabihf
    arm-unknown-linux-musleabi
    arm-unknown-linux-musleabihf
    arm64_32-apple-watchos
    armeb-unknown-linux-gnueabi
    armebv7r-none-eabi
    armebv7r-none-eabihf
    armv4t-none-eabi
    armv4t-unknown-linux-gnueabi
    armv5te-none-eabi
    armv5te-unknown-linux-gnueabi
    armv5te-unknown-linux-musleabi
    armv5te-unknown-linux-uclibceabi
    armv6-unknown-freebsd
    armv6-unknown-netbsd-eabihf
    armv6k-nintendo-3ds
    armv7-apple-ios
    armv7-linux-androideabi
    armv7-unknown-freebsd
    armv7-unknown-linux-gnueabi
    armv7-unknown-linux-gnueabihf
    armv7-unknown-linux-musleabi
    armv7-unknown-linux-musleabihf
    armv7-unknown-linux-uclibceabi
    armv7-unknown-linux-uclibceabihf
    armv7-unknown-netbsd-eabihf
    armv7-wrs-vxworks-eabihf
    armv7a-kmc-solid_asp3-eabi
    armv7a-kmc-solid_asp3-eabihf
    armv7a-none-eabi
    armv7a-none-eabihf
    armv7k-apple-watchos
    armv7r-none-eabi
    armv7r-none-eabihf
    armv7s-apple-ios
    asmjs-unknown-emscripten
    avr-unknown-gnu-atmega328
    bpfeb-unknown-none
    bpfel-unknown-none
    hexagon-unknown-linux-musl
    i386-apple-ios
    i586-pc-windows-msvc
    i586-unknown-linux-gnu
    i586-unknown-linux-musl
    i686-apple-darwin
    i686-linux-android
    i686-pc-windows-gnu
    i686-pc-windows-msvc
    i686-unknown-freebsd
    i686-unknown-haiku
    i686-unknown-linux-gnu
    i686-unknown-linux-musl
    i686-unknown-netbsd
    i686-unknown-openbsd
    i686-unknown-uefi
    i686-uwp-windows-gnu
    i686-uwp-windows-msvc
    i686-wrs-vxworks
    m68k-unknown-linux-gnu
    mips-unknown-linux-gnu
    mips-unknown-linux-musl
    mips-unknown-linux-uclibc
    mips64-openwrt-linux-musl
    mips64-unknown-linux-gnuabi64
    mips64-unknown-linux-muslabi64
    mips64el-unknown-linux-gnuabi64
    mips64el-unknown-linux-muslabi64
    mipsel-sony-psp
    mipsel-unknown-linux-gnu
    mipsel-unknown-linux-musl
    mipsel-unknown-linux-uclibc
    mipsel-unknown-none
    mipsisa32r6-unknown-linux-gnu
    mipsisa32r6el-unknown-linux-gnu
    mipsisa64r6-unknown-linux-gnuabi64
    mipsisa64r6el-unknown-linux-gnuabi64
    msp430-none-elf
    nvptx64-nvidia-cuda
    powerpc-unknown-freebsd
    powerpc-unknown-linux-gnu
    powerpc-unknown-linux-gnuspe
    powerpc-unknown-linux-musl
    powerpc-unknown-netbsd
    powerpc-unknown-openbsd
    powerpc-wrs-vxworks
    powerpc-wrs-vxworks-spe
    powerpc64-unknown-freebsd
    powerpc64-unknown-linux-gnu
    powerpc64-unknown-linux-musl
    powerpc64-unknown-openbsd
    powerpc64-wrs-vxworks
    powerpc64le-unknown-freebsd
    powerpc64le-unknown-linux-gnu
    powerpc64le-unknown-linux-musl
    riscv32gc-unknown-linux-gnu
    riscv32gc-unknown-linux-musl
    riscv32i-unknown-none-elf
    riscv32im-unknown-none-elf
    riscv32imac-unknown-none-elf
    riscv32imac-unknown-xous-elf
    riscv32imc-esp-espidf
    riscv32imc-unknown-none-elf
    riscv64gc-unknown-freebsd
    riscv64gc-unknown-linux-gnu
    riscv64gc-unknown-linux-musl
    riscv64gc-unknown-none-elf
    riscv64gc-unknown-openbsd
    riscv64imac-unknown-none-elf
    s390x-unknown-linux-gnu
    s390x-unknown-linux-musl
    sparc-unknown-linux-gnu
    sparc64-unknown-linux-gnu
    sparc64-unknown-netbsd
    sparc64-unknown-openbsd
    sparcv9-sun-solaris
    thumbv4t-none-eabi
    thumbv5te-none-eabi
    thumbv6m-none-eabi
    thumbv7a-pc-windows-msvc
    thumbv7a-uwp-windows-msvc
    thumbv7em-none-eabi
    thumbv7em-none-eabihf
    thumbv7m-none-eabi
    thumbv7neon-linux-androideabi
    thumbv7neon-unknown-linux-gnueabihf
    thumbv7neon-unknown-linux-musleabihf
    thumbv8m.base-none-eabi
    thumbv8m.main-none-eabi
    thumbv8m.main-none-eabihf
    wasm32-unknown-emscripten
    wasm32-unknown-unknown
    wasm32-wasi
    wasm64-unknown-unknown
    x86_64-apple-darwin
    x86_64-apple-ios
    x86_64-apple-ios-macabi
    x86_64-apple-tvos
    x86_64-apple-watchos-sim
    x86_64-fortanix-unknown-sgx
    x86_64-fuchsia
    x86_64-linux-android
    x86_64-pc-solaris
    x86_64-pc-windows-gnu
    x86_64-pc-windows-gnullvm
    x86_64-pc-windows-msvc
    x86_64-sun-solaris
    x86_64-unknown-dragonfly
    x86_64-unknown-freebsd
    x86_64-unknown-haiku
    x86_64-unknown-hermit
    x86_64-unknown-illumos
    x86_64-unknown-l4re-uclibc
    x86_64-unknown-linux-gnu
    x86_64-unknown-linux-gnux32
    x86_64-unknown-linux-musl
    x86_64-unknown-netbsd
    x86_64-unknown-none
    x86_64-unknown-none-linuxkernel
    x86_64-unknown-openbsd
    x86_64-unknown-redox
    x86_64-unknown-uefi
    x86_64-uwp-windows-gnu
    x86_64-uwp-windows-msvc
    x86_64-wrs-vxworks

--------------------------------------------------------------------------------
Xcode architectures
--------------------------------------------------------------------------------

https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

For makefiles you create outside of Xcode, pass the appropriate architecture
values to the compiler using the -target option. The following example shows a
makefile that compiles a single-source file twice—once for each architecture.
It then creates a universal binary by merging the resulting executable files
together with the lipo tool.

x86_app: main.c
    $(CC) main.c -o x86_app -target x86_64-apple-macos10.12
arm_app: main.c
    $(CC) main.c -o arm_app -target arm64-apple-macos11
universal_app: x86_app arm_app
    lipo -create -output universal_app x86_app arm_app

Wrap Platform-Specific Code with Conditional Compilation Macros
For C-based code, the system defines a set of macros for you to use in /usr/include/TargetConditionals.h.


--------------------------------------------------------------------------------
Apple arm64 vs arm64e
--------------------------------------------------------------------------------

https://github.com/lelegard/arm-cpusysregs/blob/main/docs/arm64e-on-macos.md

    Several new instructions were defined to implement "defensive security" against
    malware code injection. This type of code injection usually starts with a buffer
    overflow (due to a bug in an application or library) and implements
    Return-Oriented Programing (ROP) techniques when it smashes the stack or
    Jump-Oriented Programming (JOP) when it smashes other types of data structure,
    typically in the heap.

    Pointer Code Authentication (PAC):
    A deterministic but unpredictable short "signature" is added to code and data
    pointers to detect invalid injected code addresses. This signature is added in
    the 16 or 8 most significant bits of the 64-pointers, otherwise unused since no
    address space uses 2^64 bytes.

    Branch Target Identification (BTI):
    Targets of valid jump and branch instructions are identified by a special
    instruction so that using any unexpected ROP or JOP gadget address results in an
    invalid instruction.

    Apple invented arm64e...
    Defining a new ABI allows to use the full power of PAC, on data structure,
    C++ vtables, etc.
    Compiling a module with -arch arm64e marks the object code with that platform
    name. Building an application or library for arm64e requires that all
    compilation units were built for arm64e. This is why defining a new platform ABI
    is the solution to get the full power of PAC.

    -arch arm64e is specific to macOS and is available in the Apple version of clang
    only.


https://github.com/swiftlang/llvm-project/blob/apple/main/clang/docs/PointerAuthentication.rst

    Pointer authentication is a technology which offers strong probabilistic
    protection against exploiting a broad class of memory bugs to take control of
    program execution. When adopted consistently in a language ABI, it provides a
    form of relatively fine-grained control flow integrity (CFI) check that resists
    both return-oriented programming (ROP) and jump-oriented programming (JOP)
    attacks.

    Terms in use:
    - Pointer authentication is a target-independent language technology.
    - ARMv8.3 is an AArch64 architecture revision of that provides hardware support
      for pointer authentication. It is implemented on several shipping processors,
      including the Apple A12 and later.
    - arm64e is a specific ABI for (not yet fully stable) for implementing pointer
      authentication on ARMv8.3 on certain Apple operating systems.


https://developer.apple.com/documentation/security/preparing-your-app-to-work-with-pointer-authentication
Preparing your app to work with pointer authentication


--------------------------------------------------------------------------------
Microsoft cl predefined macros
--------------------------------------------------------------------------------

List predefined macros
cl /PD /Zc:preprocessor y:cl_infos.cpp > z:\Downloads\cl_macros.txt


Macros defined for system architecture windows-x86_32:
    #define _W64
    #define _M_IX86_FP 2
        Defined as an integer literal value that indicates the /arch compiler option that was set, or the default.
        This macro is always defined when the compilation target is an x86 processor.
        Otherwise, undefined.
        When defined, the value is:
        - 0 if the /arch:IA32 compiler option was set.
        - 1 if the /arch:SSE compiler option was set.
        - 2 if the /arch:SSE2, /arch:AVX, /arch:AVX2, /arch:AVX512 or /arch:AVX10.1 compiler option was set.
          This value is the default if an /arch compiler option wasn't specified.
          When /arch:AVX is specified, the macro __AVX__ is also defined.
          When /arch:AVX2 is specified, both __AVX__ and __AVX2__ are also defined.
          When /arch:AVX512 is specified, __AVX__, __AVX2__, __AVX512BW__, __AVX512CD__, __AVX512DQ__, __AVX512F__, and __AVX512VL__ are also defined.
          When /arch:AVX10.1 is specified, __AVX__, __AVX2__, __AVX512BW__, __AVX512CD__, __AVX512DQ__, __AVX512F__, __AVX512VL__ and __AVX10_VER__ are also defined.
        - For more information, see /arch (x86).
    #define _M_IX86 600
        Defined as the integer literal value 600 for compilations that target x86 processors.
        This macro isn't defined for x64 or ARM compilation targets.
    #define _WIN32 1


Macros defined for system architecture windows-arm32:
    #define _M_ARM_NT 1
    #define _M_ARM 7
        Defined as the integer literal value 7 for compilations that target ARM processors.
        Undefined for ARM64, ARM64EC, and other targets.
    #define _M_ARM_FP 31
        Defined as an integer literal value that indicates which /arch compiler option was set for ARM processor targets.
        Otherwise, undefined.
        - A value in the range 30-39 if no /arch ARM option was specified, indicating the default architecture for ARM was set (VFPv3).
        - A value in the range 40-49 if /arch:VFPv4 was set.
        - For more information, see /arch (ARM).
    #define _M_ARMT _M_ARM
    #define _WIN32 1
        Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64.
        Otherwise, undefined.

https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros
Predefined macros

    __ARM_ARCH Defined as an integer literal that represents the ARM architecture version.
    The value is defined as 8 for the Armv8-A architecture.
    For 8.1 and onwards, the value is scaled for minor versions, such as X.Y, by using the formula X * 100 + Y as defined by the ARM C language extension.
    For example, for Armv8.1, __ARM_ARCH is 8 * 100 + 1 or 801.
    To set the ARM architecture version, see /arch (ARM64).
    This macro was introduced in Visual Studio 2022 version 17.10.

    _M_AMD64 Defined as the integer literal value 100 for compilations that target x64 processors or ARM64EC.
    Otherwise, undefined.


--------------------------------------------------------------------------------
Microsoft cl installation
--------------------------------------------------------------------------------

Individual components
C++ ARM build tools (latest)
    for system architecture windows-arm32
C++ Clang Compiler for Windows
    needed to build some Rust crates


--------------------------------------------------------------------------------
Unsorted notes on compilers
--------------------------------------------------------------------------------

-Wall

Well, first, we need to start pushing back on the 00UB definition of UB.
We should all start using -fwrapv, -fno-delete-null-pointer-checks, -fno-strict-overflow, and -fno-strict-aliasing on Clang and GCC (and the equivalents on MSVC).

If writing code in a non-portable dialect of C isn't your thing,
then the -ftrapv and -fcatch-undefined-behavior flags (along with the other tools mentioned before) can be useful weapons in your arsenal to track down these sorts of bugs.
Enabling them in your debug builds can be a great way to find related bugs early.
These flags can also be useful in production code if you are building security critical applications.
While they provide no guarantee that they will find all bugs, they do find a useful subset of bugs.


https://clang.llvm.org/docs/CrossCompilation.html

https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html

https://docs.kernel.org/kbuild/llvm.html

https://blog.kowalczyk.info/article/j/guide-to-predefined-macros-in-c-compilers-gcc-clang-msvc-etc..html

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

https://mcilloni.ovh/2021/02/09/cxx-cross-clang/

https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html

https://gist.github.com/progrium/b286cd8c82ce0825b2eb3b0b3a0720a0
Setting up M1 Macs for x86 development with Homebrew
---
arch -arm64 rexx
arch -x86_64 rexx

https://doc.rust-lang.org/nightly/rustc/platform-support/wasm32-unknown-emscripten.html
wasm32-unknown-emscripten   #[cfg(target_os = "emscripten")]
wasm32-unknown-unknown      #[cfg(all(target_family = "wasm", target_os = "unknown"))]
# wasm32-wasip1 target is a WebAssembly compilation target which assumes that the WASIp1
# (aka “WASI preview1”) set of “syscalls” are available for use in the standard library.
# Prior to March 2024 this target was known as wasm32-wasi
wasm32-wasip1               #[cfg(all(target_os = "wasi", target_env = "p1"))]
# The wasm32-wasip2 target is a new and still (as of January 2024) an experimental target.
wasm32-wasip2               #[cfg(all(target_os = "wasi", target_env = "p2"))]
# The wasm32-wasip3 target is the next stage of evolution of the wasm32-wasip2 target.
wasm32-wasip3               #[cfg(all(target_os = "wasi", target_env = "p3"))]