I don't think Musl's lack of dlclose should cause any issues in real world use. The rationale is: Either behavior conforms to POSIX, but only the musl behavior

I don't think Musl's lack of dlclose should cause any issues in real world use. The rationale is: Either behavior conforms to POSIX, but only the musl behavior can satisfy the robustness conditions musl aims to provide. In particular: Under glibc's approach, libraries not designed with dlclose in mind (which may not be the libraries directly loaded with dlopen, but rather their dependencies) may leave around references to themselves in such a way that removing them from the address space results in a crash (or worse) later on. This cannot happen under musl. Managing storage for thread-local objects is much more difficult if dlclose unloads libraries. If space is to be reserved in advance (needed to guarantee no late/unrecoverable failures), supporting unloading in dlclose seems to necessitate leaking TLS memory, which largely defeats the purpose of doing the unloading in the first place. More people complain that statically linked binaries in Musl cannot call dlopen, which some things rely on.