Next up is to figure out exactly what the init call is expecting, because then you pass it OpenAL.framework all you get is:
net.java.games.joal.OpenALException: Could not open openal library.
Hmm… Yeah, that would cause a problem. :-/ Basically, this should contain the name of the OpenAL shared library for the platform, it’s needed by extal.c to dynamically load OpenAL in to the environment. I’ve been meaning to look into a more graceful way of dealing with this. In the meantime, you should be able to specify the name of the shared object (my guess is that it’ll be similar to the linux entry, but don’t quote me on that) for OS X and let the native code take it from there.
You probably want to take a look at LoadOpenAL() in extal.c since this is where the OpenAL libraries actually get loaded. (and where that exception is thrown)
Unfortunately there is no such animal in OSX outside of frameworks. A framework is a shared bundle of libraries and respective resources on OSX. The mechanism for loading function pointers from it is a tad different though.
I’ll table this for now because this is going to become a reasonably substantial change to the way the LWJGL code works - which is why I never ported their OpenAL code in the first place. They made a lot of assumptions about how things should work which just fall apart on OSX.
[quote]You probably want to take a look at LoadOpenAL() in extal.c since this is where the OpenAL libraries actually get loaded. (and where that exception is thrown)
[/quote]
Yeah, that’s what I’m looking at now and now I remember why I didn’t port OpenAL for LWJGL. To use the approach that they’ve chosen would require revamping the OpenAL framework such that its compiled into a shared library - which is not how its distributed.
This is the offending line of code:
#ifdef _AGL
handleOAL = NSAddImage(path_str,NSADDIMAGE_OPTION_RETURN_ON_ERROR);
#endif
Sorry. 
I was hopeful, since IIRC they’ve apparently gotten AF running on OS X. As I noted earlier my mac dev experience is next to nil (what little native development I have done for the mac was almost 10 years ago, so I doubt very much of it applies today!)
I hope this wasn’t too big a waste of your time. :-/
Never a waste of time. What would become necessary is a change to the build of OpenAL and some changes to JOAL. The biggie is to patch ALFactory.java so that it at least does the init call which it doesn’t now (and if this is from their current codebase I’m not sure how they’re playing sounds witout calling init).
After recompiling OpenAL into a shared library and taking on the distribution responsibility for that (because it doesn’t come that way from creative), then we can use the methodology that they’re using. Its not the ideal way of doing things however.
[quote]Yeah, that’s what I’m looking at now and now I remember why I didn’t port OpenAL for LWJGL. To use the approach that they’ve chosen would require revamping the OpenAL framework such that its compiled into a shared library - which is not how its distributed.
[/quote]
Is the answer to have the OS X version just import the OpenAL headers directly? (instead of extal.h) There are a few other calls you’d have to ifdef out (mostly the load and initialize calls), but otherwise it should work. It’s not the prettiest solution, but it might at least get us up and running.
EDIT: How is the OS X distribution of OpenAL packaged?
[quote]Never a waste of time. What would become necessary is a change to the build of OpenAL and some changes to JOAL. The biggie is to patch ALFactory.java so that it at least does the init call which it doesn’t now (and if this is from their current codebase I’m not sure how they’re playing sounds witout calling init).
[/quote]
Well, I have to admit ALFactory is mine. It’s just the calls it’s making are theirs.
[quote]After recompiling OpenAL into a shared library and taking on the distribution responsibility for that (because it doesn’t come that way from creative), then we can use the methodology that they’re using. Its not the ideal way of doing things however.
[/quote]
While not ideal, it’s also not a showstopper if it means getting something up and running in the near-term.
EDIT: Of course the question is just how much work rebuilding OpenAL as a shared library is going to be. Once again, my OS X ignorance is showing…
/**
* Initialize the OpenAL environment
*
* @return true is OpenAL was able to initialize,
* false if OpenAL was not able to intialize
*/
public static boolean initialize() throws OpenALException {
String osProperty = System.getProperty("os.name");
if(osProperty.startsWith("Win")) {
isInitialized = init(new String[] { "OpenAL32.dll" });
} else if(osProperty.startsWith("Linux")) {
isInitialized = init(new String[] { "libopenal.so" });
} else {
isInitialized = init(new String[] { "/Library/Frameworks/OpenAL.framework/Versions/Current/OpenAL"});
}
return isInitialized;
}
Okay, I will update CVS. I’ve got it working properly. Had to make a couple of changes for OSX specifics. Will work with the OpenAL.framework that you can download from Creative and will work with Garin to make sure that version is up-to-date.
JOAL OSX is done 
killer! 8) Let me know when you’ve updated CVS
BTW: I now owe you several drinks…
Okay. Merged build file is in CVS. Once you’ve got it working be sure to post the OSX Status to the forum. Thanks again.
Made a slight change to the build file.
<condition property="isUnix">
<and>
<os family="unix" />
<not>
<os family="mac" />
</not>
</and>
</condition>
You have to do this or else isUnix is still true as OSX qualifies as os family Unix. I’ve checked this change into CVS and everything seems to be building fine and all of the tests run successfully.
Greg –
Could you go ahead and update the README.txt in JOAL with the build requirements? Once you’ve done that I’ll add that info to the JOAL homepage. Thanks
I just grabbed the latest from CVS but it doesn’t come close to building for me (OS X 10.3.1 JRE 1.4.2 DP 1)
I get:
/Users/scottpalmer/dev/joal% ant
Buildfile: build.xml
init:
native-compile:
init:
compile-so:
compile-dll:
compile-jnilib:
[echo] Compiling shared library for OSX
compile-native-lib:
[echo] gcc -Ic:/j2sdk1.4.2/include -IC:/Program Files/Creative Labs/OpenAL 1.0 SDK/Headers -O3 -D_AGL -bundle -o …/…/lib/libjoal.jnilib common_tools.c extal.c eaxfactory.c eaxbind.c alfactory.c alcbind.c albind.c
[exec] gcc: Files/Creative: No such file or directory
[exec] gcc: Labs/OpenAL: No such file or directory
[exec] gcc: 1.0: No such file or directory
[exec] gcc: SDK/Headers: No such file or directory
[exec] In file included from common_tools.c:40:
[exec] common_tools.h:43:17: jni.h: No such file or directory
[exec] In file included from common_tools.c:40:
[exec] common_tools.h:61: error: parse error before ‘*’ token
…
It continues downhill from there…
Obviously it is still trying to use Windows stuff.
Done. I’ve updated README.txt and updated CVS.
Yeah, because you didn’t change the bits in build.xml that say “change to taste”. you will need to specify a few paths as the build.xml for JOAL is not as generic as that for JOGL.
Read the README.txt.
Ok, I know it won’t solve 100% of the issues… but rather than hardcode platform specific paths in the build file, lets use the same platform detection rules and hardcode typical paths for each platform.
For OS X this would be:
<property name="jdk.home" value="/Library/Java/Home"/>
<property name="openal.home" value="/Library/Frameworks/OpenAL.framework"/>
Although G.P. says that sometimes OpenAL might go elsewhere, this is where the installer form the creative site put it for me… it doesn’t give a choice.
I also had trouble building (complaints about finding assertFalse) because I had a more recent build of junit.jar in my class path.
Once I cleared that up ‘ant runtests’ worked fine. It would be great if we can get rid of those duplicate definition warnings though.
[quote]Ok, I know it won’t solve 100% of the issues… but rather than hardcode platform specific paths in the build file, lets use the same platform detection rules and hardcode typical paths for each platform.
For OS X this would be:
<property name="jdk.home" value="/Library/Java/Home"/>
<property name="openal.home" value="/Library/Frameworks/OpenAL.framework"/>
Although G.P. says that sometimes OpenAL might go elsewhere, this is where the installer form the creative site put it for me… it doesn’t give a choice.
I also had trouble building (complaints about finding assertFalse) because I had a more recent build of junit.jar in my class path.
Once I cleared that up ‘ant runtests’ worked fine. It would be great if we can get rid of those duplicate definition warnings though.
[/quote]
I’m considering this. In the meantime, I’ve commented out the jdk.home and openal.home properties in the build file, added a ALL CAPS message indicating that they must be set and uncommented, and added a task to the target which will cause the build to fail if jdk.home and openal.home are not set, iinforming the user to see README.txt for instructions. Hopefully this will reduce frustration for folks until a better solution presents itself.
Perhaps you can set the properties to reasonable defaults AND test that such folders exist… THEN spew the configuration message if they don’t. Maybe you can also mention the path issue if the build fails in general.
It would be best if it “just works” and custom setup steps can be avoided.
edit
Doesn’t Ant need to know the JDK home anyway? Can’t we get that path from Ant so it doesn’t need to be specified on a per-project basis?