Cocoapods: [Vendored Frameworks] unused architectures not stripped from dSYM

[benasher44]

🌈

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Build an archive of our iOS app

What did you expect to happen?

Unused architectures are stripped from dSYMs for vendored frameworks.

What happened instead?

The -frameworks.sh script prints that it stripped the sim arch as expected, but running file confirms that the sim arch is still there.

CocoaPods Environment

Stack

   CocoaPods : 1.7.0.beta.3
        Ruby : ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]
    RubyGems : 3.0.3
        Host : Mac OS X 10.14.4 (18E226)
       Xcode : 10.2.1 (10E1001)
         Git : git version 2.20.1 (Apple Git-117)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 0aca8de02b6d6dee6774462f8742ee5abaf4c10f
               plangrid - https://github.com/plangrid/ios-specs.git @ e82d7965317feeabed18cd99c424686dc6aa5e91

Installation Source

Executable Path: /Users/basher/Code/plangrid/vendor/bundle/ruby/2.3.0/bin/pod

Plugins

claide-plugins        : 0.9.2
cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Project that demonstrates the issue

I don't have a project to demonstrate the issue atm, but here are the things I've done to debug:

• Remove the install_dsym line from the -frameworks.sh script to verify nothing else is installing/overwriting the dsym being copied by CP
• In strip_invalid_arches, verified ARCHS only prints arm64
• In strip_invalid_arches, it prints/echos that it stripped x86_64, when the build phase runs

[benasher44]

Actually I had it print the lipo commands, and it's only running lipo -remove for the frameworks, not the dSYMs. Will update as I debug further.

[benasher44]

It's not being run because the dSYM is failing this check in install_dsym: if [[ "$(file "$binary")" == *"Mach-O dSYM companion"* ]]; then

Here's the output of file on the dsym in question:

/Users/basher/Library/Developer/Xcode/DerivedData/PlanGrid-gqlncmhpixhqencipfdoevzawlxo/Build/Intermediates.noindex/PlanGrid.build/Debug-iphoneos/PlanGrid.build/DerivedSources/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dSYM companion file x86_64] [arm64]
/Users/basher/Library/Developer/Xcode/DerivedData/PlanGrid-gqlncmhpixhqencipfdoevzawlxo/Build/Intermediates.noindex/PlanGrid.build/Debug-iphoneos/PlanGrid.build/DerivedSources/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture x86_64):    Mach-O 64-bit dSYM companion file x86_64
/Users/basher/Library/Developer/Xcode/DerivedData/PlanGrid-gqlncmhpixhqencipfdoevzawlxo/Build/Intermediates.noindex/PlanGrid.build/Debug-iphoneos/PlanGrid.build/DerivedSources/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture arm64): Mach-O 64-bit dSYM companion file arm64

[benasher44]

Looks like all of the Mach-O dSYM companion strings are broken up with that 64-bit part, which is causing the check to fail

[benasher44]

This is either a recent change in file command output or something that happens when the binary only contains 64-bit slices (all the output gets "64-bit" in it)

[benasher44]

Confirmed that this is an issue when a vendored framework stops provided 32-bit slices. Here's the old one (which would have triggered that check that was failing):

$ file Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit 
Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit: Mach-O universal binary with 4 architectures: [i386:Mach-O dSYM companion file i386] [arm64]
Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture i386):    Mach-O dSYM companion file i386
Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture x86_64):    Mach-O 64-bit dSYM companion file x86_64
Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture armv7):    Mach-O dSYM companion file arm_v7
Pods/PSPDFKit/PSPDFKit.framework.dSYM/Contents/Resources/DWARF/PSPDFKit (for architecture arm64):    Mach-O 64-bit dSYM companion file arm64

[benasher44]

The only workaround I have is to copy the *-frameworks.sh script in Pods/Target\ Support\ Files that's handling your dSYM, update the check in install_dsym to look like if [[ "$(file "$binary")" == *"Mach-O "*"dSYM companion"* ]]; then, remove all of the install_framework lines, and then add this script as a script phase that runs after CP's embed framework script

[steipete]

Ben, that's a great analysis, thanks!

@CocoapodsTeam: PSPDFKit Vendor here: If we can help, let me know. This will happen to more SDKs in the next few months as everyone will slowly drop iOS 10 once iOS 13 is out.

[dnkoutso]

Talked with @benasher44 a bit offline updating this check should be sufficient and we can ship it with 1.7.0 final which I was hoping to ship this week.

[dnkoutso]

Let's open up a PR and get this in!

[dnkoutso]

Fixed.

[steipete]

Thanks for fixing that so fast! Much appreciated! 💙

[dnkoutso]

no problem!