Unable to find libm.so with GNU ld script

[yashi]

On Debian Sid with libc6:amd64 2.33-7, libm.so is a GNU ld script just like the following. With this, libwhich libm.so doesn't find the actual libm binary.

$ git rev-parse HEAD
87cffe10080c98e7b5786c5166e420bf1ada1d41

$ ./libwhich libm.so
failed to open library: /lib/x86_64-linux-gnu/libm.so: invalid ELF header

But, does find it when I append .6.

$ ./libwhich libm.so.6
library:
  /lib/x86_64-linux-gnu/libm.so.6

dependencies:
  linux-vdso.so.1
  /lib/x86_64-linux-gnu/libdl.so.2
  /lib/x86_64-linux-gnu/libc.so.6
  /lib64/ld-linux-x86-64.so.2
+ /lib/x86_64-linux-gnu/libm.so.6

$ cat /lib/x86_64-linux-gnu/libm.so
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libm.so.6  AS_NEEDED ( /lib/x86_64-linux-gnu/libmvec.so.1 ) )

[yashi]

https://sourceware.org/bugzilla/show_bug.cgi?id=18915

[vtjnash]

I am also fairly reluctant to support this, for the same reasons that sourceware.org bug was marked INVALID. The file libm.so is not a legal name for dlopen, which is what this program is intended to be for. The correct file name is libm.so.6 on Debian. I don't really want this program to be helping maintain a fiction that the library has ever been called anything else.

[winterheart]

My intention to get "ld script resolving" is that libwhich is used for building julia. In Gentoo Linux we are using system libraries to get a build environment. At same time there are numerous libraries that cannot be used for dlopen() as libXXX.so represents as ld script wrappers (for example last notable error is unable to use system libpcre2 - https://bugs.gentoo.org/893336). We cannot force using system libm, llvm and pcre2 libraries that way.
In the Debian environment this issue can be solved by hardcoding with versioned libXXX.so.* names, but Gentoo is rolling release distribution, so we can't expect an exact SONAME library in the user's system environment. There where my PR comes to help.
IMHO libwhich is not intended to find dlopen-able libraries, as julia tries to find exact SONAME libraries.

[vtjnash]

Looks like the correct name of that library on glibc-based platforms is typically libpcre2-8.so.0. Gentoo does need to provide that exact SONAME though, as that is what the Julia build has an API for. If it is unable to provide that for some reason, then it can instead permit Julia to build the correct version (e.g. USE_SYSTEM_PCRE2=0). It doesn't seem like libpcre2 plans to make breaking changes though, since the SONAME is 0. The symlink_system_library base/Makefile target in Julia supports SONAME specification as an optional parameter (c.f. libstdc++,6 for example) though most SONAME declarations appear to be currently missing.