Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openal.so loading issues on some distros #69

Closed
Mystro256 opened this issue Jan 31, 2017 · 6 comments
Closed

Openal.so loading issues on some distros #69

Mystro256 opened this issue Jan 31, 2017 · 6 comments
Labels

Comments

@Mystro256
Copy link
Contributor

@Mystro256 Mystro256 commented Jan 31, 2017

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

This comment has been minimized.

Copy link
Collaborator

@rkitover rkitover commented Jan 31, 2017

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

This comment has been minimized.

Copy link
Contributor Author

@Mystro256 Mystro256 commented Jan 31, 2017

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 added a commit that referenced this issue Jan 31, 2017
As suggested by @Mystro256, try:

wxDynamicLibrary::CanonicalizeName(wxT("openal"))+wxT(".1")

before just the canonical name for "openal" when trying to load the
library.

Also add a utility method to quietly try loading the library, because on
wx 2.8 wxDL_QUIET does not work.
@rkitover

This comment has been minimized.

Copy link
Collaborator

@rkitover rkitover commented Jan 31, 2017

@Mystro256 @doctorwho11

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

@Mystro256

This comment has been minimized.

Copy link
Contributor Author

@Mystro256 Mystro256 commented Jan 31, 2017

Looks good to me.

@rkitover

This comment has been minimized.

Copy link
Collaborator

@rkitover rkitover commented Jan 31, 2017

@Mystro256 great! Pushed to master.

@rkitover rkitover closed this Jan 31, 2017
@Mystro256

This comment has been minimized.

Copy link
Contributor Author

@Mystro256 Mystro256 commented Jan 31, 2017

Thanks!

rkitover pushed a commit that referenced this issue Aug 15, 2019
Cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.