release: ship the real libLLVM in the Linux tarball (currently a dangling symlink)

[manar-c]

Problem

The Linux release tarball (openvaf-r-v24.0.1mob-linux-x86_64.tar.gz) does not actually contain libLLVM — only a dangling symlink where it should be:

$ tar -tzvf openvaf-r-v24.0.1mob-linux-x86_64.tar.gz
lrwxrwxrwx ... lib/libLLVM.so -> libLLVM.so.21.1
lrwxrwxrwx ... lib/libLLVM.so.21.1 -> ../../x86_64-linux-gnu/libLLVM.so.21.1   <-- points outside the archive
lrwxrwxrwx ... lib/libLLVM-21.so -> libLLVM.so.21.1
lrwxrwxrwx ... lib/libLLVM.so.1 -> libLLVM.so.21.1
-rwxr-xr-x ... 101379969 bin/openvaf-r

So on any host without a system libLLVM of the same major version (e.g. stock Ubuntu 24.04, which packages LLVM 18–20), the binary fails despite the $ORIGIN/../lib RUNPATH:

$ bin/openvaf-r --version
error while loading shared libraries: libLLVM.so.21.1: cannot open shared object file: No such file or directory

Cause

In the Package step of release.yml, cp -a copies libLLVM*.so* from llvm-config --libdir preserving symlinks. On apt.llvm.org installs, libLLVM.so.21.1 in that libdir is itself a symlink into the system multiarch directory (../../x86_64-linux-gnu/libLLVM.so.21.1), so the dangling link is copied into the package instead of the library. CI doesn't catch it because the runner does have the system library, so the dynamic loader falls back to it after the RUNPATH lookup misses.

Fix

After the copy, materialize any symlink whose target points outside the package lib/ with the real file (one full copy of libLLVM; same-directory sibling links like libLLVM.so -> libLLVM.so.21.1 are kept as symlinks and become valid), then fail the build if any broken symlink remains in the package.

Verification

• Reproduced the failure with the shipped v24.0.1mob tarball on Ubuntu 24.04 with no system LLVM 21.
• After replacing the dangling symlink with the real libLLVM.so.21.1, the same binary runs and correctly compiles the IHP SG13G2 PDK models (psp103/psp103_nqs/r3_cmc/mosvar), verified through to an ngspice-47 simulation.
• The materialize-and-check shell logic was tested standalone against a replica of the apt.llvm.org symlink layout: exactly one real copy of the library ends up in lib/, sibling symlinks stay intact, and zero broken links remain.

The macOS packaging already dereferences dependencies per-file and doesn't appear affected; the Windows step copies DLLs directly.

[Kreijstal]

shouldnt you use your distro choice of llvm?

[manar-c]

shouldnt you use your distro choice of llvm?

Part of the issue is the softlink to some other folder for that file.

[Kreijstal]

I made it so it works with original llvm from ubuntu... check if it works again pls