[openal] Further consideration of C++

[Chris Robinson]

On 10/25/18 6:26 AM, Daniel Gibson wrote:
> Bundling libstdc++ with your app and unconditionally using the bundled 
> version is just a bad idea and leads to trouble.

I'm not sure how else to do it, though. A binary distributed app may not 
want to rely on the system having a particular minimum version of 
libstdc++ installed, which means their app would fail to run if it's not 
new enough (worsened by the fact that the error message would be a bit 
cryptic, if the user sees it at all since it would be printed to the 
terminal that you wouldn't see when launching via the desktop).

There also doesn't seem to be a way to have the system select the 
highest ABI-compatible version of a lib given what it finds in the 
library paths, instead always picking based on path priority. So an app 
can only say (with a launcher script) "use my copy and hope nothing 
needs something newer" or "don't use my copy and hope the system's is 
sufficient" without knowing which is better.


I think I've found a workaround for the static-linked exported symbols, 
though. At least on ELF targets (not macOS), you can link with
-static-libstdc++ -Wl,--exclude-libs,libstdc++.a
to static link libstdc++ and prevent its symbols from being exported. If 
I simply link with -static-libstdc++, the lib's exports do get polluted 
with various __cxa and std symbols (seen with nm -g --defined-only). If 
I then also add -Wl,--exclude-libs,libstdc++.a, it excludes the symbols 
in libstdc++.a from being added to the exports and the symbol list looks 
normal again.

I'm not sure if this works to make the symbols properly hidden (i.e. not 
just prevent other libs or the app from seeing its symbols, but also not 
have its own symbols get overridden by global versions), but it looks 
promising.