Carthage: Static framework builds don't work if code coverage is enabled

[mfclarke]

• carthage install method: [ ] .pkg, [x] homebrew, [ ] source
• which carthage: /usr/local/bin/carthage
• carthage version: 0.28.0
• xcodebuild -version: 9.2 / 9C40b
• Are you using --no-build? Yes
• Are you using --no-use-binaries? Yes
• Are you using --use-submodules? Yes
• Are you using --cache-builds? No
• Are you using --new-resolver? No
• Are you using the static framework script? Yes

Cartfile

github "ReactiveCocoa/ReactiveSwift" ~> 3.1

Carthage Output

➜ carthage update --no-use-binaries --no-build ReactiveSwift
*** Fetching ReactiveSwift
*** Fetching Result
*** Checking out ReactiveSwift at "46fb4d4a8285286e54929add1d12f384675895c6"
➜ ./carthage-build-static.sh ReactiveSwift --platform ios
*** xcodebuild output can be found in /var/folders/5x/r4v95l3s3z99bnh5d_1rmrb40000gr/T/carthage-xcodebuild.WVDH36.log
*** Building scheme "Result-iOS" in Result.xcodeproj
*** Building scheme "ReactiveSwift-iOS" in ReactiveSwift.xcworkspace

Actual outcome
Carthage built a valid static framework, but when building the target that links to this framework on Simulator I get:

Undefined symbols for architecture x86_64:
  "___llvm_profile_runtime", referenced from:
      ___llvm_profile_runtime_user in ReactiveSwift(Signal.o)
      ___llvm_profile_runtime_user in ReactiveSwift(Optional.o)
      ___llvm_profile_runtime_user in ReactiveSwift(Disposable.o)
      ___llvm_profile_runtime_user in ReactiveSwift(SignalProducer.o)
      ___llvm_profile_runtime_user in ReactiveSwift(ResultExtensions.o)
      ___llvm_profile_runtime_user in ReactiveSwift(ValidatingProperty.o)
      ___llvm_profile_runtime_user in ReactiveSwift(Deprecations+Removals.o)
      ...
     (maybe you meant: ___llvm_profile_runtime_user)
ld: symbol(s) not found for architecture x86_64

It seems that the build process is adding in profiling calls, but the symbols aren't present. You can work around this in 2 ways:

1. Add -fprofile-instr-generate to the other linker flags of your target. As per this comment on a similar ReactiveSwift issue. Presumably this links the required symbols, though may slow down your binary or make your binary invalid for the app store.
2. Turn off "Gather Coverage Data" on the framework scheme's test action. This seems crazy to me, since we're not building the framework for testing. Though I don't know enough about xcodebuild or libtool to know if there is even the concept of "building for testing". But anyway, it does eliminate the issue. Though turning it off isn't ideal either, because then you don't collect needed test coverage data.

Expected outcome
I'm not sure. Either the script should somehow temporarily disable this setting in the scheme, or documentation should be updated to reflect that there's a condition for making a Carthage framework statically compilable. That is, if there is a test action for the scheme it shouldn't gather coverage data. The framework maintainer can still create a separate test scheme with coverage enabled.

[tmspzz]

@mfclarke can you point me to the script that you are using?

[mfclarke]

Hi @blender I'm following the docs here: https://github.com/Carthage/Carthage/blob/master/Documentation/StaticFrameworks.md

[tmspzz]

are you overriding LD ?

I suggest you:

• fork ReactiveSwift
• change it's mach-o type to static-lib
• try with that fork and no script

There is a carthage branch that builds static libs too but it's under development. Support is not official. Using static frameworks is very much experimental I'm afraid.

[XavierDK]

I think you should add -fprofile-instr-generate in your other linker flags.

[mfclarke]

@XavierDK I worry that building with that flag will trigger some private API warnings when submitting to the store. And adding bloat to the binary

[mfclarke]

I haven't forgotten about this @blender. I should be able to provide more info in the next day or two.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tmspzz]

@mfclarke 0.30.0 contains support for static frameworks. Is this still an issue? Can you close if it does not appear anymore?

[alphatroya]

No, it does, only disabling Code Coverage in framework settings fix build on the simulator

[elitalon]

We are experiencing a similar issue in an iOS app, but only when building for "Release". Using a "Debug" build configuration works.

[elitalon]

@mfclarke Can't you add -fprofile-instr-generate only to Simulator builds?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thomaslange]

I can confirm the

• …problem with the environment I posted below
• …comment from @alphatroya https://github.com/Carthage/Carthage/issues/2363#issuecomment-402175327

---

• carthage install method: [ ] .pkg, [x] homebrew, [ ] source
• which carthage: /usr/local/bin/carthage
• carthage version: 0.31.1
• xcodebuild -version: Xcode 10.0 Build version 10A255
• Are you using --no-build? no
• Are you using --no-use-binaries? no
• Are you using --use-submodules? no
• Are you using --cache-builds? no
• Are you using --new-resolver? no

[tmspzz]

If anyone wants to help, PRs are welcome ;)

[oscahie]

I'm not very familiar with Cartage but here's my 2cts: I ran into the same issue when distributing my own framework and IMHO the best workaround is to pass CLANG_ENABLE_CODE_COVERAGE=NO to xcodebuild when preparing a release (or alternatively set that in your xcconfig file), which will actually instruct the compiler not to generate the instrumentation necessary for the code coverage feature. Your framework users won't be able to leverage that feature anyway, so it's not only pointless to leave it enabled but it'll also increase the memory footprint and hinder the performance of the framework. Adding -fprofile-instr-generate to the linker flags is therefore only hiding the problem away, not solving it.

Of course the real fix would be in Apple's hands, since Xcode should be smart enough to disable code coverage when making builds not intended for testing.