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

Library loading overcomplicated #21

Open
Artoria2e5 opened this issue Apr 28, 2023 · 0 comments
Open

Library loading overcomplicated #21

Artoria2e5 opened this issue Apr 28, 2023 · 0 comments

Comments

@Artoria2e5
Copy link

Artoria2e5 commented Apr 28, 2023

Library loading isn't great right now. It works, but it does unnecessary things and changes things that should not be changed.

In library_loader.py:

load_other

PATH change will not affect library resolution at all on Linux, macOS, or FreeBSD. The semicolon also is not how they do PATHs. The current code only serves to destroy the last entry of $PATH.

arch_style: Is this permutation really necessary?

On Windows, the standard name is always just "OpenAL32", regardless of architecture, because history. With how al_lib loads things, the correct value is empty in the common case. In the uncommon case a user is really shipping and naming the dll, the arch bits might make sense, but all these aliases? How hard is it to have the user fix a name?

On "Other", the basic name is just "openal". When 32 and 64 coexist, they usually reside in different folders, but can also huddle together in the same fat binary, or have a name difference. In any case, the loader should not touch it, because Python's magic knows better. It will consult ldconfig on os.name == "posix", which is the real authority and has arcane magic better than everyone here.

_windows_styles

The lib{} bit is surprisingly justified, because MinGW calls it libopenal-1.dll. It still would not work though.

But _dynamic? Why would anyone name a dll that? If it's static, it would not be a dll...

_other_styles

The lib{} bit is not justified because Python knows to add it on mac and to, again, consult the Old Ones on other systems.

In al_lib.py

soft_oal being in front is a bit opinionated for an "OpenAL" library. alsoft is very cool, but doing this just doesn't do what it says on the bottle. The constants for alsoft's fun extensions also aren't there.


Recommendation:

  • remove all the styles except lib{} for win.
  • remove the path handling completely. it's not even used by al_lib!
  • define a way to bypass the search logic and call ctypes.CDLL directly at import for actually usable customization (you don't even need find_library: it's either there or not there, and LoadLibrary / dlopen knows more about the paths). Maybe an environmental variable, since passing stuff at import is pretty difficult.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant