> The "master" project now cannot link against the subproject's libraries
> when building with the Release configuration. The library search paths
> include the build products locations for the subproject, and it definitely
> sees this project's library before any system libraries of the same name
> (e.g. LIBRARY_SEARCH_PATHS=../../Security\ Libraries/build/Release
> build/Release). The errors I get are:
> /Xcode2.5/usr/bin/../libexec/gcc/i686-apple-darwin8/4.0.1/libtool: for
> architecture ppc object: ../../Security
> Libraries/build/Release/libcrypto.dylib malformed object (unknown load
> command 9)
> /Xcode2.5/usr/bin/../libexec/gcc/i686-apple-darwin8/4.0.1/libtool: for
> architecture: (null) file: -lcrypto is not an object file (not allowed in
> a
> library)/Xcode2.5/usr/bin/../libexec/gcc/i686-apple-darwin8/4.0.1/libtool:
> for architecture i386 object: ../../Security
> Libraries/build/Release/libcrypto.dylib malformed object (unknown load
> command 10)
>
> I can perform some simple tasks with otool on that file (../../Security
> Libraries/build/Release/libcrypto.dylib) without any reported problems, it
> seems that there's some mismatch between what the subproject has provided
> and what the linker needs to link against the main project... but what is
> that mismatch? :-)
Some more information that I'm not sure how to use - the command in the
build process which fails is of the form:
/Xcode2.5/usr/bin/g++-4.0 -o /path/to/built/product.dylib [options...]
if I run this manually with the Xcode 3.0 compiler - i.e. replacing
/Xcode2.5/usr/bin/g++-4.0 with /usr/bin/g++ - then the link succeeds, and
the rest of the Xcode build can continue.
Thanks,
Graham.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
This email sent to email@hidden
