On Friday March 06 2015 12:33:05 t...@qx.net wrote: > It looked to me like libffi is the one in error, so below is a grep of > libffi.6.dylib from the original install attempt:
Yes. This command > libtool: link: /opt/local/bin/gcc-apple-4.2 -dynamiclib -o > .libs/libffi.6.dylib src/.libs/prep_cif.o src/.libs/types.o > src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o > src/powerpc/.libs/ffi_darwin.o src/powerpc/.libs/darwin.o > src/powerpc/.libs/darwin_closure.o -L/opt/local/lib -Os -arch ppc > -Wl,-headerpad_max_install_names -arch ppc > -Wl,-headerpad_max_install_names -arch ppc -install_name > /opt/local/lib/libffi.6.dylib -compatibility_version 7 -current_version > 7.4 -Wl,-single_module should not produce this error message: > dyld: Library not loaded: /opt/local/lib/libffi.6.dylib > /opt/local/lib/libffi.6.dylib: incompatible cpu-subtype That's an error that is posted by dyld, the dynamic loader, when trying to start an application that links to libffi. You'll need to find the link command(s) that use `-lffi` and add the -force_cpusubtype_ALL option. Unless Ryan knows a way to change the CPU subtype stored in libffi... What's strange is that it has apparently been created with the a generic -arch flag, but maybe gcc-apple-4.2 replaces that with a G4 setting? R. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
