I've narrowed it down, it turns out that it was one of my dependent libraries that was "corrupt" which is why I didn't seem to be able to undo this. I ran into this a while ago, but it hadn't seemed that urgent, until today!
Basically, when building my dependent LIBX, like this:
g++ -c -g1 -O -Wno-non-template-friend -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -o LIBX.o LIBX.cpp g++ -g1 -O -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o libLIBX.dylib LIBX.o -dynamiclib -lm;
The output seems to be corrupt, otool -L shows:
libLIBX.dylib: /var/tmp//cc40rumz.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
However, recompiling and omitting -arch i386, the library is ok, otool shows:
libLIBX.dylib: libLIBX.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Adding -install_name libLIBX.dylib doesn't fix it:
libLIBX.dylib: /var/tmp//ccaymkrr.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) libLIBX.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
And attempting to change the /var/tmp//...out filename using install_name_tool doesn't work either.
Note that LIBX makes extensive use of STL and C++ in general (templates etc.).
Thanks.
|