A statically linked application (the static namespace), and the dynamically loaded libraries (the dynamic namespace), and any dlmopen'd libraries (newly created link namespace), all need to coordinate in some minimal way to avoid some of the following problems: * Don't double initialize the same global variable if it has a non-default value. * If threads are loaded, then each of the namespace must be informed of this and act accordingly. * If a function touches errno, this errno has to be shared across the namespaces, and all other global state variables that need to be shared between the static "namespace" and the dynamic "namespace." Fixing this is going to be quit a bit of work and it won't get fixed soon. We'll need some kind of collected shared global state we can pass to the new namespace which allows the implementation to behave sensibly. The conclusion at Red Hat was to continue to investigate the issue upstream, but that statically linked applications would be very very small and not likely to use any of the features which trigger this problem.
*** Bug 1283710 has been marked as a duplicate of this bug. ***
Your implication that static dlopen and dlmopen face the same problem is incorrect. Some aspects are similar, the static dlopen problems are simply bugs. The dlmopen issue is more of a design problem.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Upstream deprecates static dlopen in glibc 2.27.
See comment 2. I'm going to close this bug as too broad. Static dlopen issues will be fixed once we do not use static dlopen for NSS and gconv. dlmopen isuses are quite different, as I said, and it remains to be seen what we can do there.