[openal] Further consideration of C++

[michael kapelko]

Hi.
Is it possible to simply provide openal soft as single header file? No
headaches then.
On Fri, 26 Oct 2018 at 20:55, Daniel Gibson <metalcaedes at gmail.com> wrote:
>
> 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
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal