[SOLVED] OpenAL

Compiling or Editing the Panda Source
1

Hi, quick questions:

(1) What is the difference in the 3rd party dir between : openal/lib/pandaopenal32.lib and openal/lib/OpenAL32.lib? (windows)

(2) I’m rebuilding openAL directly from the last ‘soft openAL’ release. Can I simply use my new generated OpenAL32.lib and forget about pandaopenal32.lib?
EDIT: Done it (ie just forgetting pandaopenal32.lib) and it works fine…

2

OpenAL32.lib is OpenAL itself. pandaopenal32.lib is the Panda code that connects Panda to OpenAL.

David

3

Sorry to sound dumb (I’m learning everyday) but why is it located in 3rd party directory then?
makepanda.py:

    if (PkgSkip("OPENAL")==0):
        if (os.path.exists(GetThirdpartyDir() + "openal/lib/pandaopenal32.lib")):
            LibName("OPENAL",   GetThirdpartyDir() + "openal/lib/pandaopenal32.lib")
        else:
            LibName("OPENAL",   GetThirdpartyDir() + "openal/lib/OpenAL32.lib")
4

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).

David