OSX need help

[gregorypierce]

I need to throw away the current build.xml file because it absolutely won't work on OSX and many other platforms. What i need to find now is where the gcc command is defined that the build.xml keeps kicking off so I can edit it for OSX. I don't see it anywhere in the joal hive

Stuck. Once I can get past this - won't take long. Have tested out the new OSX OpenAL and its performance doesn't suck for a change

[sugarshark]

What i need to find now is where the gcc command is defined that the build.xml keeps kicking off so I can edit it for OSX.

Hi Greg,

look into $JOAL_HOME/src/native/build.xml

Ole

[gregorypierce]

Much appreciated. FInding that solved a great many problems. Now to just figure out why gcc still isn't seeing the header files when its invoking

1	gcc -I/System/Library/Frameworks/JavaVM.framework/Headers -I/Library/Frameworks/OpenAL.framework/Headers  -O3 -D_X11 -shared -Wl,-soname -Wl,libjoal.so -Wl,-export-dynamic  -o ../../lib/libjoal.so extal.c eaxfactory.c eaxbind.c alfactory.c alcbind.c albind.c

Even when its looking at the directories where the headers are located, its still saying that they aren't there. Driving me nuts

Any ideas? I'm not too familiar with gcc.

Games published by our own members! Check 'em out!

[gregorypierce]

Found the source of the problem - 10.2.8 is just horribly broken. I had to change the system to compile with JDK1.3.1.

1	gcc -I/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Headers -I/Library/Frameworks/OpenAL.framework/Headers  -dynamiclib -framework JavaVM  -framework OpenAL -o ../../lib/libjoal.jnilib extal.c eaxfactory.c eaxbind.c alfactory.c alcbind.c albind.c

So now I have it to where everything should build IF I weren't getting some issues with the definitions of the functions:

    [exec] extal.h:161: undefined type, found `ALCdevice'
    [exec] extal.h:162: undefined type, found `ALCdevice'
    [exec] extal.h:163: undefined type, found `ALCdevice'
    [exec] extal.h:164: undefined type, found `ALCdevice'
    [exec] extal.h:165: undefined type, found `ALCcontext'
    [exec] extal.h:165: undefined type, found `ALCdevice'

Taking a look at the header file extal.h I've run across

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27

#ifdef _WIN32  #ifdef _OPENAL32LIB   #define ALCAPI __declspec(dllexport)  #else   #define ALCAPI __declspec(dllimport)  #endif  typedef struct ALCdevice_struct ALCdevice;  typedef struct ALCcontext_struct ALCcontext;  #define ALCAPIENTRY __cdecl #else  #ifdef TARGET_OS_MAC   #if TARGET_OS_MAC  typedef struct ALCdevice_struct ALCdevice;  typedef struct ALCcontext_struct ALCcontext;      #pragma export on   #endif  typedef struct ALCdevice_struct ALCdevice;  typedef struct ALCcontext_struct ALCcontext;  #endif  #define ALCAPI  #define ALCAPIENTRY

So I'm not sure why its saying that they don't exist.

[aNt]

r we still stuck on this?

[gregorypierce]

yeah, still stuck on this. Haven't gone back to it in a few - went to a bachelor party and still recovering....

[Athomas Goldberg]

I've updated extal.c & extal.h from the latest version of the LWJGL (from which the original was taken) There have been a number of changes made to the files, especially around OSX, so it may be worth taking another look at getting it working. I don't currently have a Mac available or I'd try to figure it out myself. Hope this helps!

[gregorypierce]

I'm on it. Downloading now.

[Athomas Goldberg]

Great! I can't promise anything, since 1) I didn't write extal.c or extal.h, I merely borrowed them from LWJGL and 2) I haven't really done any development for OS X. That said, I figured it was worth mentioning that the files had been upgraded in the hopes that it will make a difference. Good luck!

[gregorypierce]

We still need to fix the ant build script. It still thinks the build succeeds even if compile-native-lib throws errors.

Games published by our own members! Check 'em out!

[Athomas Goldberg]

We still need to fix the ant build script. It still thinks the build succeeds even if compile-native-lib throws errors.

I'm open to suggestions.  I haven't figured out a graceful way to let ant know that the gcc compile has failed. I'll keep looking around on the web, though, maybe somebody's figured it out already.

[gregorypierce]

I've gotten it to build. Haven't actually tried to do anything with it. I had to make some pretty significant changes to the build scripts in order to make it happen and for now I'm going to leave that as an excercise for the 'file merge specialists' to determine. I do know that the "isUnix" thing is problematic because OSX "isUnix" just as Linux is  

Here is the build file I used to get the compile for OSX natives

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46

<project name="Sun Games Initiative Client Technologies" basedir="." default="all">     <target name="init">     <property name="cc" value ="gcc"/>     <property name="no_cygwin" value="-mno-cygwin"/>     <property name="sources" value="common_tools.c extal.c eaxfactory.c eaxbind.c alfactory.c alcbind.c albind.c"/>     <property name="specs" value="-specs='./specs.new'"/>     <condition property="isUnix">             <os family="unix" />     </condition>     </target>       <target name="compile-jnilib" depends="init" if="isUnix">         <echo message="Compiling shared library for OSX" />         <antcall target="compile-native-lib">             <param name="include" value="-I${jdk.home}/include -I${openal.home}/Headers" />             <param name="compilerflags" value ="-O3 -D_AGL -bundle "/>             <param name="output" value="../../lib/libjoal.jnilib"/>         </antcall>     </target>     <target name="compile-native-lib">       <echo message="${cc} ${include} ${compilerflags} -o ${output} ${sources}" />         <exec executable="${cc}">             <arg line=" ${include} ${compilerflags} -o ${output} ${sources}"/>         </exec>     </target>     <target name="compile" depends="compile-jnilib">      </target>     <target name="javadoc" depends="init">         <ant dir="src/java" target="javadoc"/>     </target>             <target name="all" depends="init,compile" description="Build everything.">         <echo message="Application built."/>     </target>         <target name="clean" description="Clean all build products.">         <delete file="../../lib/libjoal.jnilib" />     </target> </project>

[gregorypierce]

Cannot yet speak to whether or not it works. It should, but there were some warnings that cropped up:

1   2   3   4   5   6   7   8   9   10   11

[exec] In file included from extal.c:34:      [exec] extal.h:82: warning: redefinition of `ALCboolean'      [exec] /Library/Frameworks/OpenAL.framework/Headers/alctypes.h:30: warning: `ALCboolean' previously declared here      [exec] extal.h:85: warning: redefinition of `ALCbyte'      [exec] /Library/Frameworks/OpenAL.framework/Headers/alctypes.h:33: warning: `ALCbyte' previously declared here      [exec] extal.h:88: warning: redefinition of `ALCubyte'      [exec] /Library/Frameworks/OpenAL.framework/Headers/alctypes.h:36: warning: `ALCubyte' previously declared here      [exec] extal.h:91: warning: redefinition of `ALCshort'      [exec] /Library/Frameworks/OpenAL.framework/Headers/      [exec] /Library/Frameworks/OpenAL.framework/Headers/alctypes.h:60: warning: `ALCvoid' previously declared here      [exec] ld: warning -prebind has no effect with -bundle

(Note that the list was trimmed to fit within the boundary of legal messages for the forum, bit the trim was done in the middle with the prebind warning being the last in the file)

[Athomas Goldberg]

Once you've gotten something that runs (he said crossing his fingers) I'll take a look at merging the build files.  At least this is a step in the right direction!

[gregorypierce]

Note that the runtests task will fail because the OpenALTest code is trying to open up the hardcoded DirectSound3D device. Don't know enough about OpenAL yet to fix that, but I'll take a look and report back tonight (this morning) if I find out what OSX expects.

[Athomas Goldberg]

You can try replacing "DirectSound3D" with null, which should cause it to use the default device.

[Athomas Goldberg]

I just updated OpenALTest and Sound3DTest to use null instead of "DirectSound3D". Once you've updated the source, you should be able to call the "runtests" task in the build.xml file.

[gregorypierce]

Throwing a NullPointerException when trying to get the device. I'll open it up in a debugger and see what's up.

[Athomas Goldberg]

Keep me posted...

Also, you probably did this, but make sure you update everything, not just the native files.

[gregorypierce]

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

/**      * 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 {             // OSX                    }         return isInitialized;     }

I believe this is the culprit Naughty naughty piece of code... Clearly there is something here that wants a platform specific. Its evil because its buried fairly deeply in source code. After this I need to figure out that the native init method wants to do with it.

[gregorypierce]

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.

[Athomas Goldberg]

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.

[Athomas Goldberg]

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)

[gregorypierce]

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.

[gregorypierce]

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)

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:

1   2   3

#ifdef _AGL             handleOAL = NSAddImage(path_str,NSADDIMAGE_OPTION_RETURN_ON_ERROR); #endif

[Athomas Goldberg]

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.  :-/

[gregorypierce]

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.

[Athomas Goldberg]

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.

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?

[Athomas Goldberg]

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

Well, I have to admit ALFactory is mine. It's just the calls it's making are theirs.

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.

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

[gregorypierce]

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

/**      * 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