Date: May 26, 2006 2:26:39 PM PDT
Subject: Re: Is there a way to determine what default options are passed to g++?
Garth,
Thank you for responding.
This project is built with a makefile only, Xcode is not directly involved (except for the tools installed).
Both machines are running Xcode 2.2.1 with the same components. Both are running Tiger 10.4.6. So far as I can tell (not expert in this), the build environments are identical. I base this educated guess on doing this at the terminal(s):
g++ -v
which yields:
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)
<<< on the PPC
and this:
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)
<<< on the Intel
Is that enough info about the build systems? If not let me know what more you want and how to find it. If I remember correctly (3 weeks ago) I upgraded Xcode on my powerbook and installed the same version on the IntelMini at the same time.
I also did a name dump (nm) on these two libs, and there are some differences. For example, the first few lines of the PPC build look like:
libJEngineUniversal.jnilib(dylib1.o):
u __mh_dylib_header
libJEngineUniversal.jnilib(JEngine_Model.o):
00000d84 T _JNI_OnLoad
00051a28 S _JNI_OnLoad.eh
00001348 T _Java_JEngine_Model_calcfft
00051edc S _Java_JEngine_Model_calcfft.eh
0000215e T _Java_JEngine_Model_calcflow
0005217c S _Java_JEngine_Model_calcflow.eh
but the Intel-build looks like:
libJEngineUniversal.jnilib(dylib1.o):
u __mh_dylib_header
libJEngineUniversal.jnilib(JEngine_Model.o):
00000dd0 T _JNI_OnLoad
00051a30 S _JNI_OnLoad.eh
00001380 T _Java_JEngine_Model_calcfft
00051ee4 S _Java_JEngine_Model_calcfft.eh
00002196 T _Java_JEngine_Model_calcflow
00052184 S _Java_JEngine_Model_calcflow.eh
The only diff I see is the offsets. Which I kind of suspect is the problem, but I don't know what to do about it.
As for what "works" means. Our JNI is included in our Java app, and loaded with a System.loadLibrary(theJNI) call. In the three successful cases (PPC-built running on PPC, Intel-Built running on Intel, and Intel-built running on PPC), the library loads and I can call into it. In the failure case (PPC-built running on Intel) the JNI loads okay (tracing in the debugger), but as soon as I get to the first call into the JNI, I get booted out with a "The Debugger has exited due to signal 11 (SIGSEGV)" message. I can't (or at least don't know how to) step into the JNI itself, but we are dying at that first actual call into it.
(I can't really go to Xcode 2.3 yet. I am on a modem out in the "wilds" of Sonoma County. Maybe next week when I am down in Berkeley.)
Thanks again for taking an interest,
Paul