Building iPhone static library for armv6 and armv7 that includes another static library [duplicate]

This question already has answers here: How can I avoid "duplicate symbol" errors in xcode with shared static libraries? (3 answers) Closed 2 years ago.

I have an Xcode project that has a "master" static library target, that includes/links to a bunch of other static libraries from other Xcode projects.

When building the master library target for "Optimized (armv6 armv7)", an error occurs in the last phase, during the CreateUniversalBinary step. For each .o file of the libraries that is included by the master library, the following error开发者_开发技巧 is reported (for example, the FBConnectGlobal.o file):

warning for architecture: armv6 same member name (FBConnectGlobal.o) 
in output file used for input files: /Developer_Beta/Builds/MTToolbox/MTToolbox.build/Debug-iphoneos/MTToolbox.build/Objects-normal/armv6/libMTToolbox.a(FBConnectGlobal.o) 
and: /Developer_Beta/Builds/MTToolbox/MTToolbox.build/Debug-iphoneos/MTToolbox.build/Objects-normal/armv7/libMTToolbox.a(FBConnectGlobal.o) 
due to use of basename, truncation and blank padding

In the end, Xcode tells that the build has succeeded. However, when using the final static library in an application project, it won't build because it finds duplicate symbols in one part of build (armv6) and misses symbols in the other part of the build (armv7).

Any ideas how to fix this?

M

---

I dont think that's the answer at all. It will totally work if you don't have two architectures in there. In the example given in the link, it is possible to link libraries a, b, and c into one library, and link with that.

The problem that Carl is having is that there are two different architectures in the library (arm6 and arm7) and the linker is failing to resolve them correctly.

I found the problem. Its a bug in libtool as far as I can tell. See my post for a solution:

https://binaryfinery.wordpress.com/2010/06/11/universal-static-library-problem-in-iphone-sdk/

---

Another fix I found is to set Architectures to "armv6". ARCHS_STANDARD_32_BIT changed from armv6 to "armv6 armv7" which aggravates the libtool bug you describe above. Obviously it won't be producing armv7 optimized binaries, but it should still work fine on iPhone 4.