fix link flags of suffix versioned libs

[xiaopeng-tranxmart]

Problem

When a versioned shared library (e.g. libcheryl.so.3.8) is used, the current behavior generates linker flags such as:

• rustc -dylib=cheryl
• gcc -lcheryl

These flags assume the presence of an unversioned shared library (libcheryl.so). As a result, linking fails when only versioned libraries (e.g., libcheryl.so.3.8) are available:

ld: cannot find -lcheryl

The correct linker options in this case should explicitly reference the versioned .so:

• rustc -Clink-arg=-l:libcheryl.so.3.8
• gcc -l:libcheryl.so.3.8

Solution

IMO, the current implementation assumes that users always provide unversioned shared libraries (libxxx.so). This assumption is too restrictive:

1. Some libraries do not provide an unversioned .so symlink (e.g., only libxxx.so.X.Y exists)
2. Library naming may not follow the libxxx.so convention (e.g., xxx.so.1)
3. Users may require fine-grained control over linker arguments, especially for ABI-specific or version-pinned dependencies

This PR updates the linking behavior as follows:

• If the library file name matches the conventional form lib<name>.so, generate -ldylib=<name>
• Otherwise, pass the exact file name to the linker via -Clink-arg=-l:<filename>

[krasimirgg]

Could you check how this interacts with get_lib_name_for_windows? (I'm a bit worried that this check is overly specific to linux and may regress windows.)

[xiaopeng-tranxmart]

Good catch. It appears that the library search behavior on Windows and Darwin differs from Linux. Since I’m not familiar with those platforms, this change is currently limited to Linux only.

[krasimirgg]

Thank you!