Re: [musl] dynamic linker is capturing "reserved" library names erroneously

[Szabolcs Nagy <nsz@port70.net>]

* Christopher Sean Morrison <brlcad@mac.com> [2022-07-27 19:06:24 -0400]:
> First consideration, the code seems to take a position that those library names are somehow universally reserved and I believe that to be incorrect.

the way libraries are looked up is not specified in detail and
the standard gives the permission to implementations to decide.

some library names are special, but in conforming environment
this is only observable via the c99 tool so that's where this
is specified, the language does not know anything about libraries.

one exception is dlopen which has

  If file contains a <slash> character, the file argument is used
  as the pathname for the file. Otherwise, file is used in an
  implementation-defined manner to yield a pathname.

so if you want reliable behaviour you need a path with /
e.g. in your example ./librt.so would have worked fine.

i believe the reason musl has to special case the names in ld.so
is to be able to load libraries linked against glibc. another
reason is to support looking up symbols in librt etc via dlsym.

> For background context, I maintain BRL-CAD, a large open source CAD system that has been in development for over 40 years.
> BRL-CAD’s flagship API with thousands of integrations around the world is the “librt” ray tracing library.

this would not work eg on older glibc if one of your dependencies
used clock_gettime. there is a reason why the c99 tool spec says
that the behaviour is unspecified if you have another librt in the
lookup path, this is a fragile setup.

i think if you want to avoid porting work then you should fix this
name collision on your side.

of course musl can also be fixed to be more friendly to such usage,
but it's not obvious how to tell if a librt.so is a user library or
part of libc (or glibc in case glibc abi compat is used).