Using SupportKit (2.10.1) with Xcode 7 causes lots and lots of warnings

[ekurutepe]

SupportKit added through CocoaPods.

Xcode 7 shows hundreds of warnings similar to the following two:

warning: Could not resolve external type c:objc(cs)NSDate
while processing /Users/ekurutepe/Development/myapp-ios/Pods/SupportKit/SupportKit.framework/SupportKit(SKTMessage.o):

warning: /var/folders/wx/0_hjrq2j6px2mwqb2yln07v00000gn/C/org.llvm.clang.Mike/ModuleCache/1FPYCAC9U2QBN/UIKit-2LM3EQU7VVY4O.pcm: No such file or directory
while processing /Users/ekurutepe/Development/myapp-ios/Pods/SupportKit/SupportKit.framework/SupportKit(SKTSwipeView.o):

[mspensieri]

Is your app written in Swift or Objective-C?

[ekurutepe]

It uses a bit of both.

On 13.09.2015, at 15:39, Mike Spensieri notifications@github.com wrote:

Is your app written in Swift or Objective-C?

—
Reply to this email directly or view it on GitHub.

[andreaperizzato]

Same for me.
Switching back to version 2.10.0 solves the problem.

[mspensieri]

@ekurutepe @andreaperizzato I haven't able to repro this with clean projects in both Obj-C and Swift, is there any project specific setting you are overriding that you think could help reproduce this issue? Or if either of you could create a small sample project that demonstrates the warnings, that would be super helpful!

Also, do you have the latest cocoapods gem? gem update cocoapods

[andreaperizzato]

Hi @mspensieri!
The warning are generated when creating the dSYM file.
No idea why, but new projects created with Xcode 7 have the following "Debug Information Format" set by default:

Old projects have DWARF with dSYM File in the debug configuration as well.
If you set it the old way, you should see the warnings.

[mspensieri]

@andreaperizzato Thanks for the info, but I still couldn't repro with these settings. Here's the test project I'm using: https://www.dropbox.com/s/xbjaqk0yzt11wfx/TestWarnings.zip?dl=0

Just pod install and it should be good to go, but I don't see any warnings

Is there something else I'm missing?

[andreaperizzato]

You should also set Enable Bitcode to NO, then clear the Derived Data folder and finally re-build the project.

[johankool]

Setting Enable Bitcode to NO negates the purpose of this update. I have the warnings too. I am not using cocoa pods, but a git submodule. Could it be that released version of the framework was a debug build? The fact that it seems to try to get a .pcm file that doesn't exist seems to indicate that. @mspensieri may not see it, because he build the framework, so he has the missing file on his computer?

[johankool]

With the TestWarnings project I see the warnings too. (Xcode 7.0 (7A218) on OS X 10.11 (15A282b))

[mspensieri]

@johankool You're right about me not seeing the warnings because I built the framework. Just noticed the path in @ekurutepe 's original comment is hardcoded to a path on my machine, i.e. org.llvm.clang.Mike. I've been able to reproduce the warnings with a build from a colleague's machine.

The warnings are certainly related to dSYM generation, as they occur only when attempting to generate the dSYM file for the integrating app. More details to come, thanks everyone

[mspensieri]

v2.10.2 is out addressing this issue. Please try it and let me know how it goes :)

[andreaperizzato]

v2.10.2 works fine for me!

[johankool]

For me too. Thanks!

[ShengtaoLei]

@mspensieri
The framework i developed has met the same problem，will you please let me know how did you fix this problem. I used cocoapod to package framework. Any suggestion is appreciate .

[eclipse-za]

Hi @mspensieri ,

Having the exact same issue with one of my frameworks. Would you mind pointing us in the right direction as to what you changed?

[mspensieri]

@ShengtaoLei @eclipse-za I solved this issue by enabling full debug symbol stripping from builds with configuration "release"

DEPLOYMENT_POSTPROCESSING =YES;
GCC_GENERATE_DEBUGGING_SYMBOLS = NO;
GCC_SYMBOLS_PRIVATE_EXTERN = YES;

[jameswangz]

Thanks @mspensieri, I used your settings and my framework works now.

It seems the size of my framework reduces about 40% after applying the settings due to the the debug symbols were stripped, I want to know are there any downsides to use the settings? Will it affect the users of my framework? I followed Jeff Verkoeyen's https://github.com/jverkoey/iOS-Framework to build the framework and he suggested disable code stripping.

Thanks,
James

[MaxGabriel]

I was able to fix the warnings using the settings @mspensieri recommneded, but I suspected this would remove debug information from my library. To test this I intentionally threw an exception from my library, and the stacktrace was just hex addresses. I'm pretty sure that GCC_GENERATE_DEBUGGING_SYMBOLS = NO; causes this.

[mspensieri]

@MaxGabriel You're right, disabling this flag will cause your binary to not include debug symbols and thus it will not be symbolicated in crash reports. From what I've read though, enabling bitcode in general makes symbolication impossible, since Apple re-compiles your app on their side and doesn't expose the dSYM.

Happy to hear alternate solutions if anyone finds one!

@jameswangz the only downside I've seen is what @MaxGabriel pointed out

[jameswangz]

Yes, today I found I was not able to debug into my Framework any more in Xcode after setting GCC_GENERATE_DEBUGGING_SYMBOLS = NO, it brings some troubles because I usually use the debugging feature to debug my Framework, not sure if there are some other ways to fix this.