Openal.so loading issues on some distros

[Mystro256]

Some distros only package the unversioned libopenal.so library in the openal development package, which can cause the following to fail in src/wx/openal.cpp if the openal development package isn't installed:

!Lib.Load(wxDynamicLibrary::CanonicalizeName(wxT("openal")))

because it canonicalizes to "libopenal.so".

This can be annoying for packaging, as a non-development package depending on a development package defeats the purpose of making the split in the first place.

I maintain the Fedora package, so I'm going to work around this by just adding ".1" to the canonicalized name, but realistically I don't think this is the "correct" solution.

My solution looks something like this:

!Lib.Load(wxDynamicLibrary::CanonicalizeName(wxT("openal"))+".1")

As the library SHOULD be loaded as libopenal.so.1, not libopenal.so. I would hope someone with more experience can patch and resolve this issue.

Thanks!

[rkitover]

We really need to switch to linking openal at compile time, I'm not sure what the reason for the dynamic loading was in the first place.

In the meantime, I think what you are proposing is perfectly fine to do on non-windows/mac.

[Mystro256]

Sounds good! Linking openal at compile really does make more sense, as SFML is typically built with openal support anyway. I assume the idea was to avoid the mandatory dependency, but that's a bit redundant now with the ENABLE_OPENAL option available.

[rkitover]

@Mystro256 @doctorwho11

Ok I think I have a fix, take a look at 44382a7 and let me know what you think.

[Mystro256]

Looks good to me.

[rkitover]

@Mystro256 great! Pushed to master.

[Mystro256]

Thanks!