[Openal] OpenalSoft 1.7.411 & malformed version number on ppc G5 and i386 macbook ok

[Chris Robinson]

On Friday 10 April 2009 4:53:48 pm Manolache Adrian wrote:
> It works without specifying any additional devices( in  ~/.alsoftrc for
> instance) . In the initial phase it did not work because of a rather weird
> thing: it seems that the application seeks libportaudio here:
> /usr/local/lib/libportaudio.2.0.0.dylib
>    /usr/local/lib/libportaudio.2.dylib
> I wondered it may be something with the paths embedded in the frameworks.

> I'm starting to think the neccessity of the existence of
> libportaudio.2.0.0.dylib  libportaudio.2.dylib in /usr/local/lib is due to
> some setup made when configuring compilation of the library. If this is so,
> how should i configure the compilation of portaudio to be able to embedd it
> in an application bundle so the deployment of the application should not
> rely on the existence of portaudio on other computers and neither to a
> separate phase where i would install this library in
> /usr/local/lib querying for su rights? 

By default, OpenAL Soft tries to load libportaudio.2.dylib using dlopen. I 
guess in this case, dlopen doesn't search the application's bundle. In Linux, 
a program could set the LD_LIBRARY_PATH env var when running the app to extra 
paths for libs, then dlopen would search those paths when trying to load the 
libs..

eg, a game's directory would be like:
./libs/
./libs/libopenal.so.1
./mygame
./mygame.x86
..etc..

./mygame would be:
#!/bin/sh
cd "`dirname $0`"
export LD_LIBRARY_PATH=./libs:$LD_LIBRARY_PATH
./mygame.x86 $*

So when the shell script is run, it'll execute the actual mygame.x86 binary 
and use the libraries in its own libs/ directory. I'd think OSX can work the 
same, but I have no idea. Perhaps you can set LD_LIBRARY_PATH to look in the 
bundle?

Optionally, you can build OpenAL Soft without dynamic loading. If you run 
cmake with the -DDLOPEN=OFF switch, it will be configured to "hard link" with 
PortAudio.. which would require the portaudio lib to load for the OpenAL Soft 
lib to load; perhaps that would work better if you're putting it in a bundle.

> Another problem deals with openal-soft, When compiling my application in
> debug and linking everything goes fine but when i compile in release mode i
> receive linking errors for OpenAL specific functions like(missing):
> alSourceStop, alDeleteBuffers, alSource3f, alBufferData, etc. I'm wondering
> what am i missing here since the same libraries are used for debug and
> release mode. 
> I compiled OpenAl Soft and use it in debug and release with netbeans on
> linux and everything works like charmed. 
> What should i do?

This is odd, though. I have no idea what would cause this if the linker 
options are the same. Don't forget, though, order is important; if you use a 
lib that uses OpenAL, it must be on the command line before OpenAL is.
-lopenal -lalure
..would generate errors (the openal functions used by alure would not be 
found), but..
-lalure -lopenal
..would work. Not having XCode, or really any other IDE, I can't really help 
(actually I do use KDevelop on occasion, but I generally use a custom CMake 
setup).