Oh, you’re right, my mistake. I was confusing this with libp3openal_audio.lib, which is the actual Panda interface with OpenAL.
Probably pandaopenal32.lib is another copy of OpenAL32.lib, but renamed to be unique. At one point we went through and renamed all of the third-party libraries used by Panda, so there would be less chance of confusion with a different version of the library already installed on the user’s machine.
In this case, since replacing OpenAL32.lib had the desired effect, it appears that we’re actually using that library, and not pandaopenal32.lib. It’s likely that at some point in the past, someone didn’t know about the renamed library, and installed a newer copy of OpenAL32.lib and made makepanda.py compile against that one instead of the renamed one. So the renamed one may just be leftover cruft now.
In any case, the renaming really doesn’t matter much for standalone .lib files; they’re compiled directly into the Panda code and aren’t going to conflict with users’ libraries. It’s really more of an issue for .dll files (and their associated .libs).