glad it works for You 
Yeah, guys you are right, I forgot to check it in before leaving for a week :roll:
Should be ok now, sorry.
Cool, got it. Unfortunately, on my PPC, any code now refuses to run with a bus error. This is both with my own code (which works, save for the "native geom" problem reported above when I revert to the old binary) and with the tests from CVS (So far I've only tried lesson 3 of the tutorial.)
Just had a look at the crash report, but unless I'm missing something it doesn't look terribly helpful. Might try my hand at creating a universal binary build tonight and debugging this, but if anyone else can reproduce and or help then that'd be appreciated as well, as my debugging/C abilities are weak.
hmm, that's a shame and I don't know why this does not work on ppc - either it's a compiler problem (universal was compiled on intel mac) or it's a problem with the 64bit support.
That reported function looks like this:
JNIEXPORT jlong JNICALL Java_org_odejava_Odejava_getNativeAddr
(JNIEnv *jenv, jclass jcls, jlong swigCPtr) {
void* id = (*(void *)swigCPtr);
return (jlong) id;
}
It works on Win/Lin/32/64 and on Intel Mac - might it be a problem on ppc???
The directory impl/ode/lib/src contains instructions. It would be great if you could try that (I have no mac available currently).
irrisor said:
The directory impl/ode/lib/src contains instructions. It would be great if you could try that (I have no mac available currently).
The directory contains the instructions for linux, not for mac, and I'm not able to translate them (because I don't know how g++ works). Someone has the rigth command line to compile the libraries for mac?
Strange, it really seems my tortoise is broken 
- the new instructions were not checked in in either:
....
Universal binaries for MacOSX (ppc+intel)
- check you have a recent version of autotools (newest version from fink suits)
- add some additional parameters to the ODE configure call (possibly correct paths, note --enable-release won't work) :
export CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
export CXXFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
./configure --disable-dependency-tracking
- compiling and linking java binaries with adding "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk":
g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -DHAVE_CONFIG_H -I. -Iinclude/ode -O2 -fno-strict-aliasing -fomit-frame-pointer -ffast-math -Iinclude -Iinclude -IOPCODE -IOPCODE/Ice -I$JAVA_INCLUDE/linux -I$JAVA_INCLUDE -DdTRIMESH_ENABLED -c -o ../odejava/odejava_wrap.o ../odejava/odejava_wrap.cxx
g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -DHAVE_CONFIG_H -I. -Iinclude/ode -O2 -fno-strict-aliasing -fomit-frame-pointer -ffast-math -Iinclude -Iinclude -IOPCODE -IOPCODE/Ice -I$JAVA_INCLUDE/linux -I$JAVA_INCLUDE -DdTRIMESH_ENABLED -c -o ../odejava/odejava.o ../odejava/odejava.cpp
g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -dynamiclib `find ode/src -name *.o` ../odejava/odejava_wrap.o ../odejava/odejava.o -o lib/libodejava.so
where is the "configure" script? I can't find it.
Whitout it, I only obtain a lot of compile errors…
thanks
The configure script is generated by autotools. Follow the ode build instructions for building ode.
I wasn’t able compile the mac PPC native library :’(
but I found that in /odejava/ode/config/user-settings the row
PRECISION=DOUBLE
must be changed in
PRECISION=SINGLE
Maybe this is the problem… or not? :?
Yes, that should be changed (the configure script does this though) - but it's not the problem 
Ack, just tried rebuilding here, hoping that just might resolve the issue, but I'm still experiencing the same segfault.
I had a thought that might go nowhere, but I suppose it can't hurt to ask. The directions in the readme.txt seem to be intended for being run from within the ODE checkout directory, yet they refer to the C++ files as being in …/odejava. They're in impl/ode/lib/src, however. Since we've had issues getting files into CVS, is it possible that there's an impl/ode/lib/src/odejava directory with updated C++ sources that we don't have? Or should the readme be updated to refer to things in …/ instead?
And has anyone else had a chance to look at this? I'm a VoiceOver user, and regrettably, VO doesn't as of yet play very nicely with XCode, and when I try running my application under gdb hoping to get a backtrace on the error, VO locks up. I'd like to be of help in resolving this, but my hands seem tied as thoroughly as they'd be if I didn't have a Mac. Just tried getting a coredump, but that didn't offer any useful information–at least, none that I noticed. Is there anything else I might do to help?
There is no ode in the jME Physics repo, no. You can check it out to where you want - the readme just refers to my structure (which is not required).
You can try to change the above method body (in odejava.cpp) back to
return **(jint **)&swigCPtr;
(removing the first line)
If this makes it operational again I have to figure out a better method to support 64bit platforms as ppc then seems have to issues casting a pointer to a java long and back again :|
Aha! One problem solved. Again, haven't done C++ in a while, but I did a bit of conditional compilation and now my application doesn't crash, at least. Here's what I changed the function to:
// Need to handle things slightly differently due to PPC weirdness.
#ifdef __ppc__
JNIEXPORT jlong JNICALL Java_org_odejava_Odejava_getNativeAddr
(JNIEnv *jenv, jclass jcls, jlong swigCPtr) {
return (jint) swigCPtr;
}
#else
JNIEXPORT jlong JNICALL Java_org_odejava_Odejava_getNativeAddr
(JNIEnv *jenv, jclass jcls, jlong swigCPtr) {
void* id = (*(void* *)swigCPtr);
return (jlong) id;
}
#endif
For some reason, I couldn't do a check for MAC_OS_X, and this should probably check for both MAC_OS_X and __ppc__ to be most portable. I'm also not sure if this would work under intel macs. Does anyone know how preprocessor symbols work with universal binaries? Are there two compiler passes, one with each symbol defined?
Unfortunately, the above-referenced native geom problem is still present in this build. :( Can any other PPC mac user confirm this? Thoughts on what should happen next?
err, you omitted the dereference and reference markers (the stars) - this should not work. But you claim that the tests run fine with that?!
edit: oh, now I get it: you mean you get that "Geom with native address xyz not found!" message - that's expected - try with the stars.
Ah, knew there was a reason I hated lower-level languages. OK, this seems to work under OS X. Thanks for putting up with my lack of knowledge/attention.
fine! Then we have a fix - thanks for testing this. I have committed the source code change to cvs.
Now we only need someone to build a universal binary… did you already build with both architectures?
"file" says so, but I don't have an intel on which to test, and again, I don't know how setting preprocessor symbols works with multiple architectures (I.e. if I test for ppc and conditionally compile then is there only one compilation pass made, or is there a second defining i386 and not ppc (or whatever the X86 preprocessor symbol is?))
But, anyhow, the binary is up at http://www.thewordnerd.info/files/libodejava.jnilib. MIME type is text/plain, so beware.
Replacing only on ppc should be fine as it was working for intel mac before. And yes, the compiler is run twice, so it should work.
Thanks for the file! It's uploaded to cvs.
@all: please test the file also on intel mac
thanks thewordnerd!!! XD
Now I'm able to use jmephysics on my PPC mac!