fix(build): broken shared library symlinks on Linux with dynamic-link

[Ryaningli]

On Linux, CMake produces a soname symlink chain for shared libraries:
libllama.so -> libllama.so.0 -> libllama.so.0.0.8233

The previous code used glob("*.so") which only matched the top-level symlinks (libllama.so), and std::fs::hard_link on a symlink creates another symlink rather than a hard link to the real file. This left target/release/ full of broken symlinks with no actual .so files.

Fix by:

• Changing glob pattern from ".so" to ".so*" to match all files in the soname chain
• Introducing copy_lib_asset() which uses symlink() for symlinks and hard_link() for regular files, correctly recreating the entire symlink chain in the target directory

[MarcusDunn]

not sure if merge broke, but CI need to be passing before I can merge. Thanks for the PR!

[MarcusDunn]

I'm not sure this is required, can we get confirmation of the bug this fixes?

[Ryaningli]

I'm not sure this is required, can we get confirmation of the bug this fixes?

Hi, thanks for taking a look.

The core fix is in commit 0e08c56 — when building with the dynamic-link feature on Linux, CMake produces a soname symlink chain like:

libllama.so -> libllama.so.0 -> libllama.so.0.x.x

The previous code used glob("*.so") which only matched the top-level symlink (libllama.so), and std::fs::hard_link on a symlink creates another dangling symlink rather than linking to the real file. This left target/release/ full of broken symlinks — ldd would report "not found" and any binary expecting to load libllama.so at runtime would fail.

To reproduce:

1. Build with cargo build --features dynamic-link on Linux
2. Check target/release/libllama.so* — before the fix, only the top-level .so symlink exists and points to nothing

You can also verify by running ldd target/release/ and seeing libllama.so => not found.