[openal] Further consideration of C++

Daniel Gibson metalcaedes at gmail.com
Fri Oct 26 13:53:11 EDT 2018


On 26.10.2018 19:10, Chris Robinson wrote:
> 
> 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.
> 

If instead of writing a launcher *script* you can write a 
launcher/wrapper in C that dlopen()s your libstdc++ and the system 
version and checks the (versioned) symbols of known libstdc++ versions.
It can then add your local dir with libstdc++ in it to LD_LIBRARY_PATH
(or not, if system version is newer) and launch the actual application 
afterwards.
I've done this in 
https://github.com/DanielGibson/Linux-app-wrapper/blob/master/wrapper.c#L177

> 
> 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.

Nice, this looks promising!


Either way, back to the original point, I don't think there is a good 
reason not to use C++ in libopenal if libGL (and probably the vulkan 
equivalent as well?) uses it, so whatever trouble C++ could cause >90% 
of OpenAL apps already get from other system libs.

Cheers,
Daniel


More information about the openal mailing list