8000 BCSymbolMaps in vendored xcframework generate invalid app archive · Issue #9681 · CocoaPods/CocoaPods · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

BCSymbolMaps in vendored xcframework generate invalid app archive #9681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 task done
CFKevinRef opened this issue Apr 3, 2020 · 10 comments · Fixed by #9888
Closed
1 task done

BCSymbolMaps in vendored xcframework generate invalid app archive #9681

CFKevinRef opened this issue Apr 3, 2020 · 10 comments · Fixed by #9888
Assignees
@amorde
Milestone
1.10.0

Comments

@CFKevinRef
Copy link

Report

What did you do?

CocoaPods 1.9.1
Xcode 11.3.1 and 11.4

The goal is to create a vendored xcframework pod with bundled dSYM and bitcode symbol maps. When the pod is consumed, archiving should pick up the dSYMs and the bitcode symbol maps.

  1. Created a pod (let's call it InternalLib) with a vendored xcframework (InternalLib.xcframework)
  2. pod install into a new project
  3. Product -> Archive in Xcode

* Like so:

- InternalLib.xcframework/
  - ios-armv7_arm64_arm64e/
    - InternalLib.framework/
      - BCSymbolMaps/
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap

What did you expect to happen?

  • Archiving succeeds and generates a valid iOS archive.
  • Apps built from this project should not have the .bcsymbolmap files as part of the app bundle

What happened instead?

Archiving completed but the Organizer window is not shown. Attempting to open the archive from Finder results in an alert with "The archive could not be installed. The archive may be corrupt or unreadable." It seems the archive only contains BCSymbolMaps/, dSYMs/, and Products/. It is missing an Info.plist as well as SCMBlueprint/ and SwiftSupport/

Also I'm noticing that apps built with this pod have that whole BCSymbolMaps/ directory included when embedding the framework.

Debugging steps taken

Removing the BCSymbolMaps directory allows the archive to complete successfully, but of course then the bitcode symbol maps from the framework are not in the resulting archive.

It seems that having that nonstandard BCSymbolMaps directory in the framework itself even just in CONFIGURATION_BUILD_DIR is incompatible with some part of the archiving process. It's not enough to simply strip this out when embedding the framework, it must be done in the artifacts script (or there just needs to be a different way to include these other than modifying a framework bundle).

As a quick hack, modifying the Prepare Artifacts script like the following seems to be a workaround. I get a successful archive and all the expected symbol maps are there.

  if [ -d "${source}/${BCSYMBOLMAP_DIR}" ]; then
    # Locate and install any .bcsymbolmaps if present
    find "${source}/${BCSYMBOLMAP_DIR}/" -name "*.bcsymbolmap"|while read f; do
      install_artifact "$f" "$destination" "true"
    done
    # hack: remove this nonstandard directory from destination
    rm -r "${destination}/$(basename "$source")/${BCSYMBOLMAP_DIR}"
    # end hack
  fi

CocoaPods Environment

Stack

   CocoaPods : 1.9.1
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
    RubyGems : 3.0.3
        Host : Mac OS X 10.15.4 (19E266)
       Xcode : 11.4 (11E146)
         Git : git version 2.25.0
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : master - git - https://github.com/CocoaPods/Specs.git @ cd0cf75c537e681401ace6836cdcf3c4cb893a0c

               trunk - CDN - https://cdn.cocoapods.org/

Project that demonstrates the issue

In progress. The current library is not suitable for public release.
@dnkoutso
Copy link
Contributor
dnkoutso commented Apr 3, 2020

Great bug report! Not sure for the actual fix here would appreciate any further investigation on what we can change here. I can make a 1.9.2 release with this.

8000
@CFKevinRef
Copy link
Author

I was thinking this could be avoided by supporting an implicit {XCFRAMEWORK_NAME}.BCSymbolMaps like is already done with {XCFRAMEWORK_NAME}.dSYMs. I have a proof of concept already working with updated CoconutLib/BananaLib examples. I'll see when I can roll it up into a PR.

@dnkoutso
Copy link
Contributor
dnkoutso commented Apr 3, 2020

great. I can guide you through the PR for whatever it needs to land.

@amorde
Copy link
Member
amorde commented Apr 3, 2020

One of the nice things about not using an umbrella {XCFRAMEWORK_NAME}.BCSymbolMaps is that we can select the ones for the correct slice, rather than including all of them.

If the issue is that we are leaving the BCSymbolMap folder behind inside the framework, that's an easy fix. I'm working on re-doing a bunch of the XCFramework stuff but was taking a break the last couple of weeks

@CFKevinRef
Copy link
Author
CFKevinRef commented Apr 3, 2020 •
edited
Loading

I agree about the umbrella directories, it just seemed to be the convention.

That said, it seems that when you "drag in" an XCFramework with the individual frameworks containing dSYMs/ and BCSymbolMaps/ directories, everything from the selected framework is copied over into the resulting archive in the appropriate place.

Perhaps that can be the officially supported configuration? Example:

- InternalLib.xcframework/
  - ios-armv7_arm64_arm64e/
    - InternalLib.framework/
      - BCSymbolMaps/
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
        - ${UUID}.bcsymbolmap
      - dSYMs/
        - InternalLib.framework.dSYM

edit: it would be really nice to be able to reuse the exact same InternalLib.xcframework for manual integration and delivery via CocoaPods, and this seems to enable that.

@CFKevinRef
Copy link
Author

Heh, another data point - Xcode (11.4) does not check (much? at all?) for validity or relevance of the .bcsymbolmap or .dSYM when archiving an app consuming an xcframework with the above structure. I dropped a simulator dSYM in the device framework and it copied over to the resulting archive.

@amorde
Copy link
Member
amorde commented Apr 5, 2020

Yep, this is why CocoaPods has to manually strip dSYMs of invalid architectures. Injecting dSYMs from vendored libraries isn't something Xcode really "supports", it's something CocoaPods provides as a value-add

@douglashill
Copy link

We are also seeing this issue with our customers integrating PSPDFKit. We believe it worked correctly in 1.9.0 (or a beta).

@amorde
Copy link
Member
amorde commented Jun 19, 2020

I’ll take a look at this during the weekend

@dnkoutso dnkoutso added this to the 1.10.0 milestone Jun 19, 2020
@amorde amorde self-assigned this Jun 29, 2020
amorde added a commit that referenced this issue Jun 29, 2020
@amorde
Remove bitcode symbol maps from embedded frameworks
3c94722 
Closes #9681
@amorde amorde mentioned this issue Jun 29, 2020
Merged
@amorde
Copy link
Member
amorde commented Jun 29, 2020

Found some time for this, PR is up #9888

@radazzouz radazzouz mentioned this issue Sep 8, 2020
Merged
3 tasks
@radazzouz radazzouz mentioned this issue Sep 15, 2020
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@amorde amorde

Labels
None yet
Projects
None yet
Milestone
1.10.0
Development

Successfully merging a pull request may close this issue.

Remove bitcode symbol maps from embedded XCFramework slices CocoaPods/CocoaPods
4 participants
@dnkoutso @CFKevinRef @douglashill @amorde
0