README.md

A fix for debugging shared precompiled binaries from Carthage.

error: Couldn't IRGen expression, no additional error

Usage

./build.sh --platform ios MyCoolFramework

build.sh

#!/bin/sh -e

XCCONFIG=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$XCCONFIG"' INT TERM HUP EXIT

echo "SWIFT_SERIALIZE_DEBUGGING_OPTIONS = NO" >> $XCCONFIG

export XCODE_XCCONFIG_FILE="$XCCONFIG"

carthage build "$@"

Make sure you delete all Carthage cached data and Xcode DerivedData before building, or I have found it may corrupt the build.

1. You need to also remove any offending library that still linked to your build paths by searching and deleting (empty trash) – if that's not possible you may need to do what Strava did.

2. I was able to test if it worked by deleting all the Carthage build folders and cache folder

   rm -rf ~/Library/Caches/org.carthage.CarthageKit
   rm -rf Carthage

3. All I had to do was set a breakpoint in another internal framework/library that we had in the app, in lldb run po self – if that failed due to IRGen, then the issue wasn't fixed.

4. lldb image list helped me see where it's loading from.

   (lldb) image list
   [  0] B430E131-7C63-32B0-B7F1-F937935A9C10 0x0000000102df4000 /Users/psolt/Library/Developer/Xcode/DerivedData/AppName-cgccgwlpvbsiwfhggackekkmufqs/Build/Products/Debug-iphoneos/AppName.app/AppName 
         /Users/psolt/Library/Developer/Xcode/DerivedData/AppName-cgccgwlpvbsiwfhggackekkmufqs/Build/Products/Debug-iphoneos/AppName.app.dSYM/Contents/Resources/DWARF/AppName
   [  1] 1F4D7499-EE60-3C5D-9D54-2CD29E4E537C 0x00000001070dc000 /Users/psolt/Library/Developer/Xcode/iOS DeviceSupport/14.4.2 (18D70) arm64e/Symbols/usr/lib/dyld 
   [  2] 5B7E6F77-8C66-315F-9282-98895A6EBE31 0x00000001076fc000 /Users/psolt/Library/Developer/Xcode/DerivedData/AppName-cgccgwlpvbsiwfhggackekkmufqs/Build/Products/Debug-iphoneos/AppName.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit 
         /System/Volumes/Data/Users/psolt/dev/Facebook/FacebookSDK/Carthage/Build/FBSDKCoreKit.xcframework/ios-arm64_armv7/dSYMs/FBSDKCoreKit.framework.dSYM/Contents/Resources/DWARF/FBSDKCoreKit
   ...

5. The key is looking for where it loads the framework, which is that indented path for each entry: /System/Volumes/Data/Users/psolt/dev/Facebook/FacebookSDK/Carthage/Build/FBSDKCoreKit.xcframework/ios-arm64_armv7/dSYMs/FBSDKCoreKit.framework.dSYM/Contents/Resources/DWARF/FBSDKCoreKit

   1. This is telling me it found the dSYM file in my Carthage Build folder, if that dSYM has hard coded paths, deleting that build folder will cause the IRGen issue to appear.

6. You can track down these unexpected locations of dSYM files if they're problematic for the architecture you're building:

   xcrun dwarfdump --uuid FBSDKCoreKit.xcframework/ios-arm64_armv7/FBSDKCoreKit.framework/FBSDKCoreKit
   
   UUID: 9B015D0E-D9CF-3660-AB4E-13BEF02FF1D5 (armv7) FBSDKCoreKit.xcframework/ios-arm64_armv7/FBSDKCoreKit.framework/FBSDKCoreKit
   UUID: 5B7E6F77-8C66-315F-9282-98895A6EBE31 (arm64) FBSDKCoreKit.xcframework/ios-arm64_armv7/FBSDKCoreKit.framework/FBSDKCoreKit

   1. That gives you insight into the UUID (lets look at the arm64: 5B7E6F77-8C66-315F-9282-98895A6EBE31), which you use to track down locations:

7. Find those locations by UUID, older versions (with hard coded paths) may still be present on your machine, which you'll need to remove.

   mdfind "com_apple_xcode_dsym_uuids == 5B7E6F77-8C66-315F-9282-98895A6EBE31"
   
   /Users/psolt/dev/codereview/libs/public/ios/FacebookSDK-ios/local 9.1.0 ios only/FBSDKCoreKit.xcframework/ios-arm64_armv7/dSYMs/FBSDKCoreKit.framework.dSYM
   /Users/psolt/dev/codereview/libs/public/ios/FacebookSDK-ios/FBSDKCoreKit.xcframework/ios-arm64_armv7/dSYMs/FBSDKCoreKit.framework.dSYM
   /Users/psolt/dev/Facebook/FacebookSDK/Carthage/Build/FBSDKCoreKit.xcframework/ios-arm64_armv7/dSYMs/FBSDKCoreKit.framework.dSYM

   1. This is telling me that my library workspace has two copies of the dSYM, one in the expected spot, and another duplicate I was testing. It also found the build folder for Carthage.
   2. If any of these locations is not the fresh build with the flags above, and it gets loaded (image list) you will see path issues on another development machine, or if you clear your build folders for Carthage/Xcode derived data.

NOTE: If there are no library code changes, the UUID may be the same value between builds. I bumped our Facebook SDK version to prevent this apparent issue, but that might not be possible depending on the library you're using (see what Strava did).

@aakarsh-sasi Did you solve your issue? I'm facing exactly the same thing and I can't get my username out of the BCSymbolMaps files.

@psolt-gpsw I did everything, every kind of clean, but my username still shows up as path.

I even checked the Carthage build log, and its passing the two variables correctly, even on swiftc.

I'm using Xcode 13.2 btw.

@caioremedio no I couldn’t fix the path after multiple trials and then I gave up in the end. If using both the flag solved this, would have saved a lot of time

@caioremedio I fixed our issue. Bumping the Facebook SDK version was important to make it different from previously used versions on our developer's machines. Otherwise, it may still reference the old build from the previous UUID and the hard-coded paths.

Did you walk through all of my steps?

@psolt-gpsw anyway to cleanup those paths without doing a version bump?

Read Strava's post: https://medium.com/strava-engineering/how-to-fix-lldb-couldnt-irgen-expression-when-using-carthage-b0a111e02497