I think the title says it all, im using OpenAL for the sound on my latest project, it works great and im pretty happy with it so far. The problem comes from users running pre 10.4 machines without OpenAL installed.


They get a crash on launch

Quote:Link (dyld) error:
dyld: /Volumes/Mini Mojo/openGLBase.app/Contents/MacOS/openGLBase can't open library: /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (No such file or directory, errno = 2)

I was under the impression if when I added the OpenAL framework to my project I copied it into my projects folder I wouldnt have this issue. Is there a way I can automaticly include the framework in the build so users without OpenAL can launch it?

As always thanks for your time everyone.

You will have to set the framework's executable_path.

Anyway, what I did was to get the latest source from CVS ( well, latest as of some months ago ) and build a static lib, which I link into my game. Works great on Panther and Tiger.

I had the same problem in a project I did before: you need to edit the install name in your executable. You must run the following command:
install_name_tool -change "/default/path/to/OpenAL/OpenAL.framework/Versions/A/OpenAL" "@executable_path/../Frameworks/OpenAL.framework/Versions/A/OpenAL" "YourExecutable.app/Contents/MacOS/YourExecutable"
(quotes included in case of spaces)

I gave that a try and still got the same errors. Few questions about the command.

1) I assume I run it from the terminal and not somewhere in xcode right?
2) I will have to run this command everytime I make a build right?
3) It targets my build and not my source right?

thanks

There are a few things you have to be sure of:
Firstly, you need to make sure you copy files build rule to copy the framework to copy the OpenAL framework. (I believe there is a special Framework rule you can choose)

Second of all, you do run that from the terminal. You also have to be sure that you are in the current directory of the app.

Third of all, you will need to do it each time you create a build, but only each time you do a release build. For your debug builds (assuming you have OpenAL installed on your computer), it is unnecessary.

akb825 Wrote:There are a few things you have to be sure of:
Firstly, you need to make sure you copy files build rule to copy the framework to copy the OpenAL framework. (I believe there is a special Framework rule you can choose)

Second of all, you do run that from the terminal. You also have to be sure that you are in the current directory of the app.

Third of all, you will need to do it each time you create a build, but only each time you do a release build. For your debug builds (assuming you have OpenAL installed on your computer), it is unnecessary.

Well, not strictly necessary to do it each time. Just copy OpenAL.framework from System into some folder in your project, say, "Frameworks/", and run the install_name_tool on it, once. Then in your XCode project have that framework be copied in in your build process. Easy enough.

Still no luck the terminal completes the command with no problems, the framework is included in my package contents but it still tries and finds it in the system folder.

stupid question: did you change the "default/path/to" and "YourExecutable" parts? I just have to ask, since I don't know why it's not working. You can also use the command otool -l "YourExecutable.app/Contents/MacOS/YourExecutable" (as in lowercase L, not upper case i) to find out where it's first searching for the OpenAL framework to make sure you're putting it in correctly.

install_name_tool -change "/System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL" "@/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL" "/Users/openGLBase.app/Contents/MacOS/openGLBase"

This look right? I tossed it in my users base folder to make things easier with the paths.

No! No! Don't change the system OpenAL! That'll fuxor it for everybody!

Make a local copy and change *that* one!

FInally, *don't* use the absolute path -- the executable path it relative to the running app. Use, exactly, "@executable_path/../Frameworks"

use

otool -L /path/to/yourapp.app/Contents/MacOS/yourapp

to see what it links to. It should say

@executable_path/../Frameworks/OpenAL.framework/Versions/A/OpenAL

probably... if it says anything beginning with @executable_path, you're probably OK; if not, you need to use install_name_tool to fix up your application. Your application may not be fixable unless it's been built with -headerpad_max_install_names.

Ok OSC its giving me the path I set
@/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)

But its still crashing on other systems because (I think) that its in a diffrent directory and isnt finding the path to the framework

Sorry guys I know this must be driving you nuts.

You want to use, the literal "executable_path" -- e.g., don't substitute with your path, use the string "executable_path".

E.g.

"@executable_path/../Frameworks/"

Not:

"/Users/path/to/app/Contents/../Frameworks/Frameworkname.framework"

The system *knows* where the app is when it's running. If you were to hardcode it, it would fail if you moved it from your build folder to your app folder. What you're doing is telling it where the framework is *in relation* to where the app is. Not where the app is.

On second thought -- use my static OpenAL lib.

http://zakariya.net/shamyl/etc/OpenAL.zip

Here's what to do.

Make two folders in your project dir, "lib" and "include". Copy libopenal.a into "lib" and the folder "OpenAL" into "include". You can see a screenshot here:


Then, add libopenal.a to your project. Then, add "include" to your header search paths and "lib" to your library search paths. Here's a screenshot of my app's setup so you can see how to use it:



Then, remove OpenAl.framework from your project.

Now, your code ought to compile just like before. You can still #include <OpenAL/OpenAL.h>

No worries about working on Panther, since libopenal.a works fine on panther and tiger and is linked into your app.

OpenAL is LGPLed, so an application linking statically to it must still meet the LGPL's conditions on relinking -- either by being open-source, or by making all the .o files available, together with a script to re-link the program.

kodex Wrote:Ok OSC its giving me the path I set
@/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)

But its still crashing on other systems because (I think) that its in a diffrent directory and isnt finding the path to the framework

Sorry guys I know this must be driving you nuts.

Wait, did you set it to @/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL by hand? Is that what it says with otool right now? If so, you aren't reading what we're saying: when we say @executable_path, we mean literally @executable_path, don't replace it with anything. If right now it is saying @/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL with otool, type this in EXACTLY (don't change a thing!) with the current directory the directory with the bundle.

install_name_tool -change "@/Users/openGLBase.app/Contents/MacOS/openGLBase/../Frameworks/OpenAL.framework/Versions/A/OpenAL" "@executable_path/../Frameworks/OpenAL.framework/Versions/A/OpenAL" "openGLBase.app/Contents/MacOS/openGLBase"

TomorrowPlusX: for install_name_tool, (with the -change option), the first parameter is the original path, the second parameter is the new path, and the third parameter is the executable name. If you want to, you can also put the executable path, then -change and the 2 framework paths (old and new). So he wasn't changing the system framework, he was changing the path to look for the framework from his executable.