Firebase-ios-sdk: Build failure when compiling PromisesObjC

[alexmx]

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.3.1
• Firebase SDK version: 6.28.1
• Firebase Component: Core, Analytics, Messages, Crashlytics, RemoteConfig
• Component version: See the resolved graph from Podfile.lock below
• Installation method: CocoaPods

Podfile.lock fragment

  - Firebase (6.28.1):
    - Firebase/Core (= 6.28.1)
  - Firebase/Core (6.28.1):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.6.2)
  - Firebase/CoreOnly (6.28.1):
    - FirebaseCore (= 6.9.1)
  - Firebase/Crashlytics (6.28.1):
    - Firebase/CoreOnly
    - FirebaseCrashlytics (~> 4.3.0)
  - Firebase/Messaging (6.28.1):
    - Firebase/CoreOnly
    - FirebaseMessaging (~> 4.6.0)
  - Firebase/RemoteConfig (6.28.1):
    - Firebase/CoreOnly
    - FirebaseRemoteConfig (~> 4.7.0)
  - FirebaseABTesting (4.0.0):
    - FirebaseCore (~> 6.8)
  - FirebaseAnalytics (6.6.2):
    - FirebaseCore (~> 6.8)
    - FirebaseInstallations (~> 1.4)
    - GoogleAppMeasurement (= 6.6.2)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (~> 1.30905.0)
  - FirebaseCore (6.9.1):
    - FirebaseCoreDiagnostics (~> 1.3)
    - GoogleUtilities/Environment (~> 6.7)
    - GoogleUtilities/Logger (~> 6.7)
  - FirebaseCoreDiagnostics (1.5.0):
    - GoogleDataTransport (~> 7.0)
    - GoogleUtilities/Environment (~> 6.7)
    - GoogleUtilities/Logger (~> 6.7)
    - nanopb (~> 1.30905.0)
  - FirebaseCrashlytics (4.3.0):
    - FirebaseCore (~> 6.8)
    - FirebaseInstallations (~> 1.1)
    - GoogleDataTransport (~> 7.0)
    - nanopb (~> 1.30905.0)
    - PromisesObjC (~> 1.2)
  - FirebaseInstallations (1.5.0):
    - FirebaseCore (~> 6.8)
    - GoogleUtilities/Environment (~> 6.7)
    - GoogleUtilities/UserDefaults (~> 6.7)
    - PromisesObjC (~> 1.2)
  - FirebaseInstanceID (4.5.0):
    - FirebaseCore (~> 6.8)
    - FirebaseInstallations (~> 1.0)
    - GoogleUtilities/Environment (~> 6.7)
    - GoogleUtilities/UserDefaults (~> 6.7)
  - FirebaseMessaging (4.6.0):
    - FirebaseCore (~> 6.8)
    - FirebaseInstanceID (~> 4.3)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.7)
    - GoogleUtilities/Environment (~> 6.7)
    - GoogleUtilities/Reachability (~> 6.7)
    - GoogleUtilities/UserDefaults (~> 6.7)
    - Protobuf (>= 3.9.2, ~> 3.9)
  - FirebaseRemoteConfig (4.7.0):
    - FirebaseABTesting (~> 4.0)
    - FirebaseCore (~> 6.8)
    - FirebaseInstallations (~> 1.1)
    - GoogleUtilities/Environment (~> 6.7)
    - "GoogleUtilities/NSData+zlib (~> 6.7)"
  - GoogleAppMeasurement (6.6.2):
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (~> 1.30905.0)
  - GoogleDataTransport (7.0.0):
    - nanopb (~> 1.30905.0)
  - GoogleInterchangeUtilities (1.2.2):
    - GoogleSymbolUtilities (~> 1.1)
  - GoogleMaps (3.8.0):
    - GoogleMaps/Maps (= 3.8.0)
  - GoogleMaps/Base (3.8.0)
  - GoogleMaps/Maps (3.8.0):
    - GoogleMaps/Base
  - GoogleNetworkingUtilities (1.2.2):
    - GoogleSymbolUtilities (~> 1.1)
  - GooglePlaces (3.8.0):
    - GoogleMaps/Base (= 3.8.0)
  - GoogleSymbolUtilities (1.1.2)
  - GoogleUtilities/AppDelegateSwizzler (6.7.1):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (6.7.1):
    - PromisesObjC (~> 1.2)
  - GoogleUtilities/Logger (6.7.1):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (6.7.1):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (6.7.1):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (6.7.1)"
  - GoogleUtilities/Reachability (6.7.1):
    - GoogleUtilities/Logger
  - GoogleUtilities/UserDefaults (6.7.1):
    - GoogleUtilities/Logger
  - GoogleUtilitiesLegacy (1.3.2):
    - GoogleSymbolUtilities (~> 1.1)

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

After upgrading to the Firebase 6.28.1 from 6.13 I've started getting occasional build failures like this:

❌  <Redacted>/Pods/PromisesObjC/Sources/FBLPromises/FBLPromise+Any.m:33:5: implicit declaration of function 'assert' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
▸     assert(!promise.isPending);

My project doesn't have Treat Warnings as Errors (GCC_TREAT_WARNINGS_AS_ERRORS) build setting enabled for any of the targets.

I've checked all of the Firebase/Google targets from the Pods folder and found that the following dependencies have this build setting enabled:

• FirebaseCoreDiagnostics
• GoogleDataTransport

By looking at the dependency graph in Podfile.lock seems like PromisesObjC dependency is needed for:

• FirebaseCrashlytics
• FirebaseInstallations
• GoogleUtilities/Environment which in turn is a dependency for FirebaseCoreDiagnostics

I would guess that the build flakiness comes from the fact that PromisesObjC can be build first as dependency for different modules which depend on it, and if one of those modules in one case has GCC_TREAT_WARNINGS_AS_ERRORS set to YES it causes PromisesObjC to fail to compile as the legit warning is treated as error. If this is the case then FirebaseCoreDiagnostics seems to be the offending modules which should have GCC_TREAT_WARNINGS_AS_ERRORS disabled. Don't understand though how that setting is getting inherited so I might be completely wrong here.

Edited: Using this workaround in Podfile seems doesn't seem to work:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['GCC_TREAT_WARNINGS_AS_ERRORS'] = "NO"
        end
    end
end

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[paulb777]

@alexmx Thanks for the report. It would be helpful to have a repro case.

From what I can see, assert.h should be included from CoreFoundation.h from Foundation.h from FBLPromiseError.h from FBLPromise.h from FBLPromise+Any.h.

What version of PromisesObjC is getting installed? See the Podfile. I'm looking at 1.2.9

[alexmx]

@paulb777 According to Podfile.lock it's PromisesObjC (1.2.9).

My Podfile workaround is not actually working, edited the original message. Unfortunately I can't reproduce it reliably to post a sample project.

[paulb777]

Hmm, we'll likely need to be able to reproduce to make progress here.

[tomasswood]

I have started getting the same issue after recently upgrading to react-native 0.63. Clearing the DerivedData 10x is the only one I can get it fixed

[schurch]

We're also seeing this error intermittently with Firebase SDK version 6.28.1 and Xcode 11.3.1. When I updated to Xcode 11.6, I've stopped seeing it and now when I try and build from Xcode 11.3.1 again I don't get the build error anymore.

[tomasswood]

When I updated to Xcode 11.6, I've stopped seeing it

I've been running on 11.6 the whole time I have been seeing the error

[dimitar-lazarov]

For us, the problem was due to Xcode default flag USE_HEADERMAP=YES and another framework containing custom assert.h file. Updating the other framework (TrustKit) version fixed the issue.

https://github.com/datatheorem/TrustKit/issues/150

[tomasswood]

Updating the other framework (TrustKit) version fixed the issue.

This seems to resolve it for us. We were using TrustKit 1.5.1 and it looks like it was patched in 1.5.2. Updating to the latest (1.6.5) is working so far.

[google-oss-bot]

Hey @alexmx. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[alexmx]

Hi @paulb777, as @dimitar-lazarov posted above the issue was related to the https://github.com/datatheorem/TrustKit/issues/150.

Not sure if Firebase can do something to be more immune to this kind of issues where another library screws things up.

[paulb777]

@alexmx I'm not sure there's much we can do if an app or another library changes accessibility of a system header.

I'll close this for now, but happy to reopen if there are any suggestions.