6

Question stated simply in title. Here is my setup:

Building a dynamic framework that optionally links (weak link) to GoogleInteractiveMediaAds.framework. For apps that use my framework, GoogleInteractiveMediaAds is an optional dependency, and the framework will work fine without it. This is currently working.

However the problem arises when attempting to rebuild from bitcode, as typically happens when exporting an Ad Hoc build with "Rebuild from Bitcode" selected. The bitcode compile process fails with:

ipatool failed with an exception: #<CmdSpec::NonZeroExitException: $/Applications/Xcode.app/Contents/Developer/usr/bin/bitcode-build-tool ...

And looking deeper into the log file I find the error description:

Failed to resolve linkage dependency MyFramework arm64 -> @rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds: Could not resolve @rpath in @rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds from MyFramework
error: GoogleInteractiveMediaAds not found in dylib search path

Note: GoogleInteractiveMediaAds.framework does include bitcode.

Obviously this error is avoiding by not selecting "Rebuild from Bitcode". If I were to answer my own question, I'd say, no, it looks like when compiling from bitcode, you cannot use weakly linked frameworks. Simply from the fact that the bitcode compilation step is trying to link to a framework which isn't included in the app target. However I haven't been able to find any official documentation surround using weak linking with bitcode, or any relevant StackOverflow answers about it, so I'm not sure if I'm missing something or if there is some relevant compiler/linker settings that I am missing to get this to work.

Matt.M
  • 1,039
  • 3
  • 14
  • 21
  • Hello ! I'm having the same issue with other libraries. The library linked is declaring another as optional, but "rebuild with XCode" is failing declaring that it can't find the optional library. Did you find any way to work around it? – SeikoTheWiz Apr 16 '20 at 13:43
  • I never did find a solution for this. It works fine when building framework from project directly. The problem was only happening to when using our project as CocoaPod dependancy. Something about CocoaPods build scripts couldn't handle building our code with a weak dependancy. I never could get an answer from them. I simply had to remove the library completely :( – Matt.M Aug 27 '20 at 00:24
  • Did the same :( – SeikoTheWiz Aug 27 '20 at 07:28

1 Answers1

3

In your case, you will need to wait for the fix in framework itself.

We've got similar issue while distributing our framework, which I described here and I just wan't to share results of our investigation, because seems that no-one has published their results.

No needs to distribute without bitcode. Long story short, there were LLVM instrumentation included, which prevents AppStore processing. I've written a whole blog about XCode 12 and BigSur issues with XCFramework.

To sum up, here is a few required steps to make sure while creating XCFramework for distribution:

  • Using archive builds is a MUST, release build isn't enough
  • BUILD_LIBRARY_FOR_DISTRIBUTION must be set to YES
  • SKIP_INSTALL must be set to NO
  • GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO to turn off GCC instrumentation and remove them from the binary
  • CLANG_ENABLE_CODE_COVERAGE = NO to turn off code coverage tools from the binary

Having all of the above helped to solve our preparing and distribution problem and hopefully save you some time if you happened to face same issues as we did.

nrudnyk
  • 924
  • 1
  • 7
  • 25