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 
[quote]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.
[/quote]
Hi Greg,
look into $JOAL_HOME/src/native/build.xml
Ole
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
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.
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.
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:
Taking a look at the header file extal.h I’ve run across
#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.
r we still stuck on this?
yeah, still stuck on this. Haven’t gone back to it in a few - went to a bachelor party and still recovering…
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!
I’m on it. Downloading now.
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!
We still need to fix the ant build script. It still thinks the build succeeds even if compile-native-lib throws errors.
[quote]We still need to fix the ant build script. It still thinks the build succeeds even if compile-native-lib throws errors.
[/quote]
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.
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 ;D
Here is the build file I used to get the compile for OSX natives
<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>
Cannot yet speak to whether or not it works. It should, but there were some warnings that cropped up:
[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)
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!
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.
You can try replacing “DirectSound3D” with null, which should cause it to use the default device.
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.
Throwing a NullPointerException when trying to get the device. I’ll open it up in a debugger and see what’s up.
Keep me posted…
Also, you probably did this, but make sure you update everything, not just the native files.
/**
* 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.