CocoaPodsWhen building the project we are getting warning:
./Pods/Headers/Public/FirebaseCrashlytics/FIRCrashlytics.h:66:37: warning: parameter of 'swift_name' attribute must be a Swift function name string
11:22:57 arguments:(va_list)args NS_SWIFT_NAME(log(format:arguments:));
11:22:57 ^
11:22:57 /Applications/Xcode11_3_1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:356:30: note: expanded from macro 'NS_SWIFT_NAME'
11:22:57 #define NS_SWIFT_NAME(_name) CF_SWIFT_NAME(_name)
11:22:57 ^
11:22:57 /Applications/Xcode11_3_1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:291:57: note: expanded from macro 'CF_SWIFT_NAME'
11:22:57 # define CF_SWIFT_NAME(_name) __attribute__((swift_name(#_name)))
11:22:57 ^
11:22:57 <scratch space>:157:1: note: expanded from here
11:22:57 "__tg_log((__typeof__(__tg_promote((format:arguments:))))(format:arguments:))"
Integrate firebase with CocoaPods and build the project.
Podfile should be like this:
pod "Firebase/Core", "6.16.0"
pod "Firebase/Messaging"
pod "Firebase/Analytics"
pod "Firebase/Crashlytics"
pod "Firebase/Performance"
We are getting the above mentioned warning.
Is there to fix this warning?
Or maybe we can(should) silence it somehow ?
Hi @hovox, since Crashlytics recommends the use of Analytics, you need to explicitly add Firebase/Analytics and no longer need to add Firebase/Core (See our docs here).
I tried to get the same behavior, but I wasn't able to reproduce it. Could you share your Podfile.lock and Podfile so I can try to replicate it on my end?
It would also be great if you could provide a minimal repro that I can run locally.
Hi @rizafran , I also could not reproduce on empty project after creating one. Digging more into the issue, I have found that it's happening because of import ordering in swift bridging header.
It happens if you import like this:
#import <GLKit/GLKit.h>
#import <FirebaseCrashlytics/FirebaseCrashlytics.h>
and does not happen if you import otherwise:
#import <FirebaseCrashlytics/FirebaseCrashlytics.h>
#import <GLKit/GLKit.h>
Do you know why it's happening ?
Thanks.
I'm not sure, but GLKit is an Apple-owned framework, so you may be able to get an answer from Apple by filing feedback.
I also tried to import like this but my app successfully builds.
#import <GLKit/GLKit.h>
#import <FirebaseCrashlytics/FirebaseCrashlytics.h>
Hi @rizafran ,
Thanks for your response.
Here is the example project in which I'm able to reproduce the issue.
You should call bundle install then bundle exec pod install.
Please take a look at firebasewarning-Bridging-Header.h file. If you change import order you should not get any warnings.
Thanks, waiting for your feedback :)
Seems to be related to the GLKit.h pulling in the clang internal header tgmath.h which defines a log macro - https://github.com/llvm-mirror/clang/blob/master/lib/Headers/tgmath.h#L460
But how it鈥檚 related to Crashlytics鈥檚 log method? Crashlytics log method seems defined in class, it鈥檚 not global function. As I understand it may cause conflicts if Crashlytics had global log function. Or not? Can you explain please?
tgmath.h defines a C preprocessor macro that gets applied to the Crashlytics header before it is semantically checked.
Thanks for explaining. I have missed that NS_SWIFT_NAME is also macro. So as I understood quick fix will be to import crashlytics before GLKit?
Yep, importing changing the import order is a workaround.
I'm going to close here since there's an easy workaround and the issue is in Apple tooling.
Thanks for the report @hovox
If someone wants to follow up with Apple, please post the updates here.
Most helpful comment
Yep, importing changing the import order is a workaround.
I'm going to close here since there's an easy workaround and the issue is in Apple tooling.
Thanks for the report @hovox
If someone wants to follow up with Apple, please post the updates here.