[openal] Further consideration of C++

[Chris Robinson]

On 10/25/18 6:31 AM, Daniel Gibson wrote:
> Apparently that doesn't really solve the problem: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1417663
> Looks like the symbols from a dynamically linked libstdc++ can still 
> clash with a statically linked libstdc++ from the system lib..

That's a bit puzzling, and unfortunate. I'd have hoped static-linking 
libstdc++ would have some way for its symbols to be hidden (to prevent 
other definitions from overriding the ones used by the lib and from 
exporting out of the lib for other things to see/use).

OpenAL Soft builds with -fvisibility=hidden on systems that support it, 
which AFAIK is standard practice for shared libraries. This should 
prevent anything not explicitly made public/visible in the lib from 
"getting out" to other libs or the app, or from being replaced by other 
libs or the app. But it seems GCC's headers force its namespaces to be 
public/visible when compiling, even if you may link with 
-static-libstdc++, where it will inevitably break if anything else pulls 
in libstdc++.so or has a different libstdc++ static-linked.

I'd have to look, but there may be a way to make all symbols defined in 
a library to be made hidden at link time, with specific ones set to be 
visible/public, regardless of how it was compiled. Ideally GCC's C++ 
headers should be fixed to not force public visibility when it will be 
static-linked (via a compile-time macro or something), but at least as 
of GCC 6.3 there doesn't seem to be a way to stop it.