I downloaded the windows x64 build of LLVM from the latest release in the repository. The zip file itself was named 17.0.6, however ld.lld --version resulted in LLD 16.0.0.

We tried at one point but it just hung. The command was

 tar cf D:\a\llvm-build\llvm-build/llvm-17.0.6-x86_64-unknown-windows-msvc17-Debug.tar.zst --zstd llvm-17.0.6-x86_64-unknown-windows-msvc17-Debug

We switched to .7z for windows but that complicates our workflows and increases latency, since you can't decompress 7z format from a stream (it needs to read the whole file before it can start).

Some of my attempts have produced incorrect binary artifacts. For example my supposed arm64 macOS binaries were actually x86_64. We ought to have a test as part of release that verfies we've built the right thing. For arm64 binaries you can at least check the output of file. Building and running something on an x86_64 builder would be nice but looks like a stretch.

Something should be done to deal with this annoyance:

In decreasing priority order:

• Using the regular procedure I've been using to run the workflow (push a tag, manually run the build on that tag, move the tag when the build fails, etc.) I often observe the sccache plugin failing to find a usable cache when it's obviously there. Caches are branch-scoped, and GitHub doesn't exactly explain what happens when you build from a tag. I suspect it's important to do all our builds on a branch (usually main) and automatically create a tag/release when that workflow succeeds.
• We might be able to get some cheap performance out of cacheing the llvm source checkout.
• The build_tools job is ridiculously stable and delays observable feedback when working on the distribution job. We could probably find a way to cache the results of build_tools and skip most of the work.

The binaries produced for arm64 linux are in fact x86_64 (and possibly also broken on that platform).

• We probably need to set CMAKE_SYSROOT

• We need to make the sysroot has the necessary content, notably libzstd

• It should work with clang. Some people do this with a dedicated g++/gcc cross-compiler but I have not had success installing one:

  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
  g++-11-aarch64-linux-gnu:amd64 : Depends: libstdc++-11-dev-arm64-cross:amd64 (>= 11) but it is not installable
  gcc-11-aarch64-linux-gnu:amd64 : Depends: binutils-aarch64-linux-gnu:amd64 (>= 2.38) but it is not going to be installed
  			    Depends: libgcc-11-dev-arm64-cross:amd64 (>= 11.4.0-1ubuntu1~22.04cross1) but it is not installable
  E: Unable to correct problems, you have held broken packages.
  

• With parallels it's easy to install an Intel Ubuntu and run it under emulation (that's one of parallels' default offerings) for work on this <==(That only lets you run x86_64 docker in the arm linux VM) if you have an arm64 machine you can use UTM to run a (slow) x86_64 ubuntu.

References:

• StackOverflow
• Cross compiling made easy
• How to cross-compile LLVM

We probably don't need to build lldb (which we currently do only on Windows). The LLDB shipped by @compnerd with his Swift packages would be more capable than anything we build.

@tothambrus11 discovered that the path to VS Enterprise is being encoded into the LLVMExports.cmake of our prebuilt LLVM distribution. He's only got Community, so nothing works for him.

As part of the build, we should postprocess the file to use VSINSTALLDIR from the environment: $ENV{VSINSTALLDIR}

dave@DaveA-MBP14-5 Swifty-LLVM % ~/Downloads/llvm-17.0.6-arm64-apple-darwin23.3.0-Debug/bin/llvm-config 
~/Downloads/llvm-17.0.6-arm64-apple-darwin23.3.0-Debug/bin/llvm-config 
dyld[27721]: Library not loaded: /opt/local/lib/libzstd.1.dylib
  Referenced from: <80280D10-861C-3C78-A1C8-3E5E93E9E2B9> /Users/dave/Downloads/llvm-17.0.6-arm64-apple-darwin23.3.0-Debug/bin/llvm-config
  Reason: tried: '/opt/local/lib/libzstd.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libzstd.1.dylib' (no such file), '/opt/local/lib/libzstd.1.dylib' (no such file), '/usr/local/lib/libzstd.1.dylib' (no such file), '/usr/lib/libzstd.1.dylib' (no such file, not in dyld cache)
zsh: abort      ~/Downloads/llvm-17.0.6-arm64-apple-darwin23.3.0-Debug/bin/llvm-config

Workaround for me is:

zstd_dir="$(pkg-config --libs-only-L libzstd)"
export DYLD_LIBRARY_PATH="${zstd_dir#-L}:$DYLD_LIBRARY_PATH"

but you have to embed it in the script invoking llvm-config because of this security feature.

That makes it useless for the results of SPM runs with --enable-code-coverage (on Linux at least).

Right now, SPM clients need to create their own, but we /could/ ship one in the package. We'd just steal the generation script from Swifty-LLVM and run that… except that I think we're getting absolute paths from llvm-config on Windows, and that could be a problem because people will decompress their LLVM packages into arbitrary locations. Something to look into.