[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