Code review comment for lp:~jpakkane/unity-scopes-api/visibility

The benefit does not come from those 12 entries. In fact I originally did not even realize they would show up. To see what the issue is let's look at an example.

Suppose we use something from the standard library, say a template std::foo<>. That uses in its implementation some other template/class/whatever, say std::foo<>::private::something. When the compiler generates code for something::method, it can do some optimizations if it knows that the method is never accessed outside the current .so. I don't know exactly what those are, but this is what GCC's documentation says. Thus -fvisibility-inlines-hidden affects classes and methods that we normally never see, as is the case here.

The performance benefit is probably minimal in this particular case, so there's no point in putting too much effort into this. However it seems the better choice to tell the compiler not to produce garbage in the first place rather than filtering it out with a linker script afterwards.

And no, you can't survive with only one of these. The documents mentioned above imply very strongly that you need both visibility definitions and a linker script to get optimal performance. This sucks, but unfortunately shared libraries are a bit of a black magic thing.