Added to CC

That is simply how STB_GNU_UNIQUE symbols behave, those symbols are pushed by the dynamic linker into a global hash table, and that makes the shared libraries non-unloadable. You can use -fno-gnu-unique if you are fine with the consequences.

If anything would change here, it would be the dynamic linker, that in theory could support tracking the reference counts of the unique symbols and unload when all of the symbols are no longer referenced.  But I guess the runtime cost could be prohibitive.

(In reply to Jakub Jelinek from comment #4)
> That is simply how STB_GNU_UNIQUE symbols behave, those symbols are pushed
> by the dynamic linker into a global hash table, and that makes the shared
> libraries non-unloadable. You can use -fno-gnu-unique if you are fine with
> the consequences.
> 
> If anything would change here, it would be the dynamic linker, that in
> theory could support tracking the reference counts of the unique symbols and
> unload when all of the symbols are no longer referenced.  But I guess the
> runtime cost could be prohibitive.

We have existing applications that rely on the fact that callback functions (such as destructors) are not unloaded.  If we start unloading DSOs when we did not do so before, these applications would be broken.  I'm not sure if this is a reasonable trade-off, although affected applications could be considered latently buggy.

So more context.

The use of the static variable in an inlined function in C++ triggers use of STB_GNU_UNIQUE symbols, which currently have the property that when used, they prevent the library from unloading.

As Jakub notes, reference counting the unique symbols so their associated libraries could be unloaded would be prohibitively expensive.  Additionally, as Florian notes, it's possible (likely?) that existing applications are relying on this behaviour and unloading when were not previously unloading could cause those applications to break.

In all, I think things are working as designed.

First of all, may be the things are working as it was worked around (or dirty hacked) some time ago. But hardly I can call this with such a word as "design" )

At least such behavior isn't documented at all in any document which a simple programmer could read. And not only me, but a lot of programmers were confused with it (according to what I've learnt when I was searching for any info on this). But hardly any of them traced the problem down to a simple example and got an answer in the gcc mailing. The feature that is not document and causes misbehavior is a bug.

The second thing is the runtime cost. But what cost we are talking about? The reference counting here happens only when additional SO is opened or closed by the process. During opening the linker should increment reference count, during close - decrement and unload SO if it not needed anymore. Do applications open and close SO often? I doubt so. Memory? Additional counter for each local static variable in the inlined method?

On the other hand, a lot of software support plugins which needs to be updated from time to time. I faced with it, when I tried to update plugin and it was not updated until program restart. And the problem was not in the plugin itself, but in the fact it was using boost library, which has somewhere a static variable in the inline method which was inlined in the plugin.

I agree with the designation of CLOSED/WONTFIX for RHEL7.

The compiler option is quite clear:

-fno-gnu-unique
On systems with recent GNU assembler and C library, the C++ compiler uses the
"STB_GNU_UNIQUE" binding to make sure that definitions of template static data
members and static local variables in inline functions are unique even in the
presence of "RTLD_LOCAL"; this is necessary to avoid problems with a library
used by two different "RTLD_LOCAL" plugins depending on a definition in one of
them and therefore disagreeing with the other one about the binding of the
symbol.  But this causes "dlclose" to be ignored for affected DSOs; if your
program relies on reinitialization of a DSO via "dlclose" and "dlopen", you can
use -fno-gnu-unique.

It is unknown how much it would cost to reference count everything and consider the DSO for dlclose. That would certainly be an interesting RFC, but it would have to start upstream.