[Openal] Linux deployment and OpenAL-Soft

[Chris Robinson]

On Friday 18 April 2008 12:28:36 pm Carsten Fuchs wrote:
> Everything works very well with the OpenAL SDK on Windows, where I've
> decided to just ship the OpenAL32.dll and wrap_oal.dll alongside the
> application executable in order to save the user from the Windows "DLL not
> found" error message and the subsequently required "manual" activation of
> the installer.

If you using an executable installer for Windows, I think it's typical to 
package with Creative's OpenAL redistributable, and to run it with the /s 
(silent) switch as part of the app's installation.

If your app doesn't use an executable installer, an idea might be to have a 
configuration option for your app so that it will run the installer on the 
first run, then set the config option so it won't run it again on subsequent 
starts. Doing it this way, however, may mean you'd have to use LoadLibrary to 
load openal32.dll since it may not exist until after the installer is run.

AFAIK, even with OpenAL32.dll in your apps directory, it'll still search the 
system directories for extra OpenAL drivers, and I'm not too sure what'll 
happen if it finds two wrap_oal.dll's (or two uniquely named DLLs that 
provide the same drivers).

> Do I understand it right that OpenAL-Soft provides me with both the headers
> and (when compiled), all the needed .so libraries, so that I don't need the
> "official" Linux files from http://www.openal.org/downloads.html at all? Is
> there any advantage in using the "official" files instead of OpenAL-Soft?
> Analogous to Windows, I'll likely want to ship the .so files as described
> in the second half of the post at
> http://opensource.creative.com/pipermail/openal-devel/2008-February/005022.
>html

OpenAL-Soft gives everything you need to build and run apps that use OpenAL, 
yes. You shouldn't need anything from the "official" downloads, unless you 
intend to use ALUT (OpenAL-Soft doesn't provide ALUT, but it will work fine 
with it).

Shipping a pre-built .so as described in that post should work fine. Just make 
sure OpenAL-Soft is built to dynamicly load ALSA (ie. it should list "ALSA"  
when you ran cmake and not "ALSA (linked)") so users that don't have ALSA can 
still use it with OSS.