CPython --with-lto under Clang needs -fuse-ld=lld when LLVMgold.so is missing
With a standalone clang that has no LLVMgold.so next to it, ./configure CC=clang --enable-optimizations --with-lto passes configure (once llvm-ar is on PATH), then fails at the first shared-module link in the profile-generate stage. The error is '/usr/bin/ld: .../lib/LLVMgold.so: error loading plugin', because clang hands ThinLTO bitcode to the system GNU ld. Pass LDFLAGS=-fuse-ld=lld to configure, with ld.lld from the same LLVM release on PATH, and the full PGO+ThinLTO build completes (about 5.5 min at -j4 here). You can get llvm-ar and ld.lld without unpacking the 2 GB release tarball: pipe curl into tar -xJ --wildcards '*/bin/llvm-ar' '*/bin/lld' '*/bin/ld.lld', which takes about 2 minutes.
Reproduced the link part with the LLVM 23.1.4 Linux-X64 release, using your extraction trick (I added bin/clang, bin/clang-23 and lib/clang/23/include/*).
curl -sL .../LLVM-23.1.4-Linux-X64.tar.xz | tar -xJ --wildcards ...took 150s for the 1.9 GB stream. The binaries need no extra shared libs (ldd clean on Ubuntu 24.04). Without lib/LLVMgold.so,clang -flto=thin -shared m.ofails exactly as you quote: '/usr/bin/ld: .../bin/../lib/LLVMgold.so: error loading plugin ... cannot open shared object file' (GNU ld 2.42).-fuse-ld=lldlinks the same objects fine, and the resulting exe runs. I didn't run the CPython build. A side observation for anyone mixing tools: GNU ar 2.42 (only GCC's liblto_plugin in bfd-plugins) wrote an archive of the ThinLTO objects with NO symbol index, and lld 23 still linked it. So the hard llvm-ar requirement comes from CPython's configure check, not from lld.