Carthage: Xcode 8b3: ABI Mismatch when copying Swift dylibs

Created on 19 Jul 2016  路  29Comments  路  Source: Carthage/Carthage

  • carthage version: 0.17.2
  • xcodebuild -version: Xcode 8.0 Build version 8S174q
  • Are you using --no-build? No
  • Are you using --no-use-binaries? No
  • Are you using --use-submodules? No

Cartfile

github "SnapKit/SnapKit" ~> 0.21.1

Carthage Output

maxmeyers$ carthage bootstrap  --platform iOS
*** Checking out SnapKit at "0.21.1"
*** xcodebuild output can be found in /var/folders/cq/tf_7hrzn5015g_2k0x_d8_2r0000gn/T/carthage-xcodebuild.gUBI2r.log
*** Building scheme "SnapKit iOS" in SnapKit.xcworkspace

During the CopySwiftLibs build phase, I see the following output. It results in the Frameworks folder being empty (except SnapKit.framework, of course).

Effective Swift version: { arm64: 3; armv7: 3; i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCore.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCore.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCoreGraphics.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCoreGraphics.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCoreImage.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCoreImage.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftDarwin.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftDarwin.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftDispatch.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftDispatch.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftFoundation.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftFoundation.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftObjectiveC.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftObjectiveC.dylib { i386: 4; x86_64: 4 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftUIKit.dylib { i386: 3; x86_64: 3 }
Found library with mismatched Swift ABI: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/libswiftUIKit.dylib { i386: 4; x86_64: 4 }

It seems like it's looking for Swift dylibs with all four architectures and can't find one. When I remove SnapKit.framework from the linked libraries, I get the following (correct) result:

Effective Swift version: { i386: 3; x86_64: 3 }
Copying /Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCore.dylib to /Users/maxmeyers/Library/Developer/Xcode/DerivedData/Swiftlibsd-haqjpklvwdwfqpgsxftryqpmovqr/Build/Products/Debug-iphonesimulator/Swiftlibsd.app/Frameworks/libswiftCore.dylib
  /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip '/Applications/Xcode-beta.app/Contents/Developer/Toolchains/Swift_2.3.xctoolchain/usr/lib/swift/iphonesimulator/libswiftCore.dylib' '-r' '-o' '/Users/maxmeyers/Library/Developer/Xcode/DerivedData/Swiftlibsd-haqjpklvwdwfqpgsxftryqpmovqr/Build/Products/Debug-iphonesimulator/Swiftlibsd.app/Frameworks/libswiftCore.dylib'
...

I have the ONLY_ACTIVE_ARCH flag set to YES (this is a debug build).

I'm not sure what the solution is, and perhaps this is just a bug with Beta 3.

Here's a sample project that reproduces the issue:
Swiftlibsd.zip

Here's the corrected example:
Swiftlibsd.zip

question

Most helpful comment

I have made a CLEAN WORKAROUND script solution which works for iPhone:
https://gist.github.com/madhavajay/39ff8bfee92e7cd97ea4270b8c99b3bc

You just add it as another Build Phase Script.
Working for iPhone Simulator and Device.

So it seems that Xcode 8 Beta 3 uses this command to copy the swift libs: builtin-swiftStdLibTool.
What ever it is, it doesn't work when you include a Framework in your app.
If you run the exact same build command but with the swift-stdlib-tool tool from the XcodeDefault toolchain it works perfectly! 馃

So I just reverse engineered how it builds the script up out of the environment variables and with some BASH-FU help from my colleagues we got it to use the Input File Params so you can specify your Frameworks the same way you would with a Carthage Copy Frameworks script.

I cannot get it to work with watchOS, but I need to leave the office if someone can work it out that would be AMAZING! 馃憤

Please let me know if you get it working on watchOS!

All 29 comments

I'm having this same issue, which is being tracked as rdar://27434450.

Does xcode-select -p match the version of Xcode that you're trying to use?

@mdiep Yes.

Have you tried deleting ~/Library/Developer/Xcode/DerivedData and/or Carthage/Build/?

I have, yes-- both. I reproduced it on a brand new, blank project as well (see above).

I was able to get it working by using '--no-build' and integrating directly.

I'm also having this issue. @maxmeyers I tried your sample project and it works fine. It seems you haven't added SnapKit.framework in "Linked Frameworks and Libraries" but after I added it "Copy Swift standard libraries" phase starts failing.

It seems to be an issue of Xcode. If you copy all the swift frameworks files into your project and then create a new build phase Copy files with destination Frameworks containing all those swift framework files, you will be able to run your project properly.

The files are located here:

/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator.

XcodeDefault.xctoolchain can be replaced with Swift_2.3.xctoolchain if you want to build/link against Swift 2.3 instead of Swift 3.0 and iphonesimulator with iphoneos if that's relevant to you.

I just created a folder/group called tmp-swift-libraries for later removal and also added the folder to the gitignore. One may create a small run script for copying those libraries before the actual build if not existing.

screen shot 2016-07-20 at 15 56 57

It is a pretty dirty workaround. Guess this bug will be fixed soon as some posts are also existing in the apple dev forums.

In addition: if running your app in the simulator, you can clearly see the missing or wrongly copied files in the container of the simulator.

Maybe this helps one.

@jsslai thanks for letting me know (oops!). I updated the sample project.

I have made a CLEAN WORKAROUND script solution which works for iPhone:
https://gist.github.com/madhavajay/39ff8bfee92e7cd97ea4270b8c99b3bc

You just add it as another Build Phase Script.
Working for iPhone Simulator and Device.

So it seems that Xcode 8 Beta 3 uses this command to copy the swift libs: builtin-swiftStdLibTool.
What ever it is, it doesn't work when you include a Framework in your app.
If you run the exact same build command but with the swift-stdlib-tool tool from the XcodeDefault toolchain it works perfectly! 馃

So I just reverse engineered how it builds the script up out of the environment variables and with some BASH-FU help from my colleagues we got it to use the Input File Params so you can specify your Frameworks the same way you would with a Carthage Copy Frameworks script.

I cannot get it to work with watchOS, but I need to leave the office if someone can work it out that would be AMAZING! 馃憤

Please let me know if you get it working on watchOS!

If anyone has any experience with my above script can they comment i'd love to know if its working and if anyone has figured out a solution to watchOS as i'm about to embark on that journey now.

@madhavajay I tried it and after some trials and errors I got it working. I had to change Xcode to Xcode-beta in script. I also thought the script would replace Carthage's copy-frameworks phase but I had to leave it and add your script.

Yeah sorry about that, I updated the script to use the TOOLCHAIN environment variable so it should work out of the box now. No it doesn't replace Carthage this is for scanning all the frameworks and collecting the necessary swift libs to embed in the app binary. Fun fact every Swift app has a copy of every needed Swift lib to maintain compatibility.

I have updated the GIST with instructions for watchOS! 馃槑

In my case, I'm using Carthage to build realm framework, everything works fine until upgrade to xcode 8b4, and crashed on libswiftAVFoundation.dylib image not found.

after using the script from @madhavajay, and add realm frameworks to input files, everything works again, thank you @madhavajay

It seems this problem has persisted with Xcode 8 Beta 4. My radar from last Beta was marked dupe so I guess its a known issue but not fixed?

Tried @madhavajay 's script, but it's not working for me. I'm getting the following when I run the app in the simulator. Any idea what might be wrong?

dyld: Symbol not found: __TMps11CVarArgType
Referenced from: /Users/derekclarkson/Library/Developer/CoreSimulator
    /Devices/277C19C2-718E-4CC2-9873-BB6E4C3A46E3/data/Containers/Bundle
    /Application/7623F6EE-8637-46AF-A80E-0775DD708CA6
    /crux-iOS.app/Frameworks/SocketIO.framework/SocketIO
Expected in: /Users/derekclarkson/Library/Developer/CoreSimulator
    /Devices/277C19C2-718E-4CC2-9873-BB6E4C3A46E3/data/Containers/Bundle
    /Application/7623F6EE-8637-46AF-A80E-0775DD708CA6
    /crux-iOS.app/Frameworks/libswiftCore.dylib
in /Users/derekclarkson/Library/Developer/CoreSimulator
    /Devices/277C19C2-718E-4CC2-9873-BB6E4C3A46E3/data/Containers/Bundle
    /Application/7623F6EE-8637-46AF-A80E-0775DD708CA6
    /crux-iOS.app/Frameworks/SocketIO.framework/SocketIO

I would suggest right click and copying the entire output of the build process for each target into a text editor, then going through looking for errors or warnings / issues, that might help locate the problem. This is how I found the issue for the swift lib tool which my fix addresses.

@madhavajay's modification of the build phase script got the project compiling for me but iTunes Connect is rejecting submissions citing "Invalid Swift Support" because the top level "SwiftSupport" directory in the built product is empty. We've given up on letting Carthage do anything build related and are now using it solely for submodule management.

@hyperspacemark interesting. We tried submitting today and got lots of "wrong" provisioning profile errors and Bitcode errors crashing Xcode. I might try pulling carthage out of the equation and seeing if that resolves it. Are you using Cocoapods then or just manually adding the frameworks to the project?

On a related note has anyone tried SPM, Carthage is really giving me the SH*%s.

Are you using Cocoapods then or just manually adding the frameworks to the project?

Adding framework projects as subprojects and embedding/linking them manually.

That sucks.... GitHub doesnt have enough emoticons for that. 馃槶

I've lodged a bug report and Apple's marked it as a duplicate. Everyone should log one as well so Apple gets the messages that it needs immediate attention. At the moment (for me) this is a show stopper, causing me to have to go back to XCode 7.3.1

How are you embedding your Carthage frameworks if I drag them into the Embedded Binaries section it has this issue. But if you follow the If you're building for iOS, tvOS, or watchOS section in the readme skipping step 3 and don't drag them into Embedded Binaries or into Linked Frameworks and Libraries just add the run script from the readme and do a clean build it works. So maybe try removing all the Carthage frameworks from the project and remove @madhavajay's script then only add the run script from the readme. Also if you have UI Tests or Unit Tests I had to use the same run script in those.

@chandlerhuff I can't confirm that. I'm using Xcode 8b5 and I exactly followed the mentioned Readme section, but I still get the error dyld: Library not loaded: @rpath/libswiftCoreLocation.dylib

@ffittschen try skipping step 3 of the readme and removing the Carthage frameworks form Linked Frameworks and Libraries and removing references to the frameworks from the project navigator and only have the build script and do a clean build.

I've always used copy-frameworks. Embedded binaries is a relatively new thing. With the script I started getting a whole problem. Something to do with var args (See reveal posts above). Anyway, until Apple fix this issue, I'll have to start away from the betas.

I had the same problem in my framework test targets. Keeping step 3 works for me as @chandlerhuff suggested

For anyone watching this: -

_XCode 8.0 Beta 6 appears to have fixed the bug._

Therefore the above scripts are no longer required. Thank you to the guys who took the time developed them.

So this should be fixed in the official Xcode 8.0 release. Closing.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

3lvis picture 3lvis  路  3Comments

CAPIStkidd picture CAPIStkidd  路  3Comments

akaffenberger picture akaffenberger  路  3Comments

faustperic picture faustperic  路  3Comments

pmhood picture pmhood  路  3Comments