Which is not the architecture being linked x86_64 ):?

 41

I've created a Swift framework project for util/extensions that compiles and copies a .framework file to a dedicated location on my system. I want to be able to include this file into other projects (Build Phases/Link Binary with Libraries). The framework project is a Cocoa Touch Framework type project (as selected from Xcode 6.1 project template browser).

But when I try compiling a project which links the framework file, I'm getting this warning:

ld: warning: ignoring file /Users/name/Projects/Xcode/Libs/swiftutils.framework/swiftutils, file was built for x86_64 which is not the architecture being linked (i386): /Users/name/Projects/Xcode/Libs/swiftutils.framework/swiftutils

Is there anything I can do with the framework project so that it is valid for other iOS projects? It's confusing because the framework project is a Cocoa Touch Framework project which should naturally work with other Cocoa Touch (i.e. IOS) projects, shouldn't it?

xcodecocoaswiftcompilationframeworks

Share

Improve this question

asked Nov 21 '14 at 7:11

BadmintonCat

9,0421010 gold badges6565 silver badges114114 bronze badges

Add a comment

6 Answers

ActiveOldestVotes

35

Make sure you have i386 and x86_64 listed in your Architectures in Build settings for your lib. Also set Build Active Architecture Only explicitly to No.

Share

Improve this answer

edited Nov 23 '14 at 8:50

answered Nov 21 '14 at 7:26

dogsgod

6,02755 gold badges2323 silver badges5353 bronze badges

• That alone doesn't seem to suffice. I've added them so that Valid Architectures reads like this: arm64 armv7 armv7s i386 x86_6 ... Getting the same error still. – BadmintonCat Nov 21 '14 at 7:33
• Ok, I'm a step further... I had to set Build Active Architecture Only explicitly to NO since it contained mixed values for debug and release. The warning is gone however: My framework API is not found in the app project. It looks like the framework classes aren't linked so I get no auto-complete hints for the framework API and the compilation fails. What could be wrong? – BadmintonCat Nov 21 '14 at 8:04
• You can have different settings for debug & release, could that be it? – dogsgod Nov 23 '14 at 8:52
• 2
  Build Active Architecture Only explicitly to No worked for me. Thanks mate. – ZaEeM ZaFaR May 13 '15 at 5:58

Add a comment

13

While the accepted answer has solved the problem, here is a little more since the problems is about the architecture, literally the binary files

1. Architecture in iOS

armv64: iPhoneX, iPhone 5s-8, iPad Air - iPad Pro

armv7 : iPhone3Gs-5c, iPad WIFI(4th gen)

armv6 : iPhone - iPhone3G

the above if for real devices

i386 : 32-bit simulator

x86_64 : 64-bit simulator

the above list is downward compatible, which means iPhoneX can runs with armv6 as well, and just can not fully utilize the functions of armv64

more info about iOS architectures can be found here: https://developer.apple.com/library/content/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html

2. What is Build Active Architecture Only?

If selected "Yes", it will only build your framework to the "selected device", either real devices(armv) or simulator(x86_64 or i386). For "No", it will build your framework to your list of "Valid Architectures"

By default, in debug mode, it is "Yes"; and in release more, it is "No", which can save compiling time in debug mode and ensure your release project framework runs on all architectures that you specified.

Thats why the accepted answer worked by forcing the framework to build for all architectures, however by reading more you will know what is behind and can definitely save time in compiling your framework. Of course, more control in yourself as well.

So, if you are working on a framework, and want to import to another project, if you compile the framework with Build Active Architecture Only "Yes" with simulator(i386 or x86_64), and then import to your project with Build Active Architecture Only "Yes" with a real device(armv), you will encountered this error.

Looking to the error description:

file was built for x86_64 which is not the architecture being linked (i386) will imply you build your framework in 64-bit simulator and your merged project build with 32-bit simulator.

while a more common would be:

framework file was built for x86_64 which is not the architecture being linked (arm64): which implies your framework is built in simulator while your merged project is build with real device.

3. Extracting the framework

A common practice would be right click the framework and select Show In Finder, while most developers keep the Finder open, and the newly compiled framework will replace the old one, without closing Finder and reopen again. Yes it is right, but if you switched the build target device in between, the frameworks will result in different folders. Sometimes you think you have compiled your framework but indeed it is in another folder. My suggestions would be always select Show in Finder to prevent the framework you import is not the latest one.

The two different folders: Debug-iphoneos and Debug-iphonesimulator 

Share

Improve this answer

edited Jun 20 '20 at 9:12

Community♦

111 silver badge

answered Mar 7 '18 at 4:18

Edison Lo

44477 silver badges2121 bronze badges

• 1
  Dude! your 3rd point 3. Extracting the framework is solid gold. I almost fell from my chair when I encountered this error. But following the 3rd step to extract the framework correctly is the right approach, The accepted answer is rather hackish. – AnBisw Mar 27 '18 at 7:05
• 1
  The framework in it's original project must be compiled and built once in the the os level/device that the project is targeting and also in simulator. The resulting .framework files then need to be picked from the correct folder as in 3rd step to import to the new project. – AnBisw Mar 27 '18 at 7:11
• 1
  thanks you, I just dev with Xamarin.Form in VS2019, and don't know much about mobile developement world, just spent 3 hours to deal with IOS simulator on this issue....the Native Reference could not build in X86_64 – Cheung Mar 7 '20 at 18:50 

Add a comment

8

I ran into this problem and the current solution got rid of the original error (i.e. unable to link i386), but then linked Frameworks (such as Alamofire) could not be imported into my project. The following solution fixed this problem.

1. In your target Build Settings -> Architectures -> Valid Architectures, add the value i386.

2. Next, delete the contents of your project's derived data folder. The contents of this folder are generated during build time and can be safely removed and Xcode will create a new one. To delete this folder in Xcode 8, go to File->Project/Workspace Settings, click on the grey arrow to open the folder location in Finder, and delete the contents. 

3. Clean and rebuild.

4. If the build still fails, check the issue navigator for something that says Update to recommended settings. Click it and try again.
   If you don't see that option, change Build Active Architecture Only to Yes in build settings. This slows down build times which can be frustrating when switching between different devices frequently, however it might be necessary.

Share

Improve this answer

edited Dec 21 '16 at 19:39

answered Sep 2 '16 at 23:34

darksinge

1,1201414 silver badges2525 bronze badges

• 1
  It worked for me. I'm using Xcode 7.0.1. Thank you!! – lgm Sep 11 '16 at 2:59
• 1
  interestingly, i had it manually set to NO before and it used to work. updated to swift 3 and it broke. reverted to YES and things are fine again. go figure.. – joe Nov 22 '16 at 23:58
• 1
  Where is "Valid Architectures" in XCode 8? – Maiaux Dec 21 '16 at 15:09
• 1
  @Maiaux It's still in build settings. If you look at the first picture I have in this answer, you'll notice there is a search bar. Type valid in it and Valid Architectures will show up. Also make sure you have the All button selected. if Basic is selected it might not show up in the search results. – darksinge Dec 21 '16 at 18:40 
• @darksinge I was getting the same error and I followed your step it worked for me while I ran the code in simulator. But when I tried to run the code in device got error "ignoring fil.., file was built for x86_64 which is not the architecture being linked (arm64):" then I followed the same step with arm64 but the error still persist. – reetu Apr 11 '17 at 16:09 

Show 3 more comments

2

I also found that if you are using frameworks through cocoapods as I was, I had to go to the Pods project, and apply solutions by @dogsgod and @darksinge for every framework target in the Pods project. That is, I had to turn off build for active architectures only and add X86_64 and i386 in valid architectures.

Share

Improve this answer

answered Apr 12 '17 at 21:19

Jitendra Kulkarni

80366 silver badges1717 bronze badges

Add a comment

2

I had this exact same error for another reason. The iOS deployment version for the main app was 10.0, and it was 11.0 on the framework. As 11.0 allows only 64 bits, the framework was compiled for 64 bits only. And when the app wanted to link with the framework in 32 bits, I had this warning :

file was built for arm64 which is not the architecture being linked (armv7)

Followed by a linker error because of course lot of symbols from the missing framework were not found.

So changing the deployment target to iOS 10.0 on the framework fixed it. Changing the deployment target of the app to iOS 11.0 would probably fix it too (generating a 64 bits only binary).

Share

Improve this answer

answered May 7 '19 at 16:46

jptsetung

8,66833 gold badges3838 silver badges4949 bronze badges

• I have the same error when am making build archive. I changed the iOS deployment target iOS 11.0. How do i change deployment target to iOS 10.0 on the framework? – Ashwini Salunkhe Aug 8 '20 at 6:16

Add a comment

0

Upgrading from React Native 57.8 to 58.4 introduced this linker issue. Wasn't a framework error though. Above methods did not work, but what fixed it for me was deleting the Test from Targets section in xCode. Didn't need it so this was fine for us. Example would be project named SuperCool has TARGETS: SuperCool, SuperCoolTests, SuperCool-tvOS, and SuperCool-tvOSTests. Delete SuperCoolTests to fix.