Closed jas4711 closed 8 months ago
Sorry, this got lost. So, on no developer systems this breaks since the .so does not exist? I thought there is always a symlink.
Sorry, this got lost. So, on no developer systems this breaks since the .so does not exist? I thought there is always a symlink.
No, the .so symlink are not standard: look at any newly installed Debian, Ubuntu, Fedora etc system for any library such as OpenSSL or even libc. This approach is used by other libraries too, I recall that libc dlopen() some libraries such as libidn2.so and then it uses the libidn2.so.X interface too.
podman run --arch amd64 -it --rm debian:12
...
root@3b2ee07b4cad:/# ls -la /usr/lib/x86_64-linux-gnu/libc.so*
-rwxr-xr-x 1 root root 1926256 Jan 30 18:20 /usr/lib/x86_64-linux-gnu/libc.so.6
root@3b2ee07b4cad:/# ls -la /usr/lib/x86_64-linux-gnu/libssl.so*
-rw-r--r-- 1 root root 692256 Feb 3 16:11 /usr/lib/x86_64-linux-gnu/libssl.so.3
root@3b2ee07b4cad:/#
OK, merged in.
The rationale is that on most normal systems, there is no gppcscconnectionplugin.so symlink but only a gppcscconnectionplugin.so.1. The .so symlink is only on developer systems. It may look strange to hard-code the shared library version here, but we already hard code the shared library name. What do you think?