Protobuf: 'protobuf/Any.pbobjc.h' file not found

[Interfere]

I use CocoaPods to add Protobuf to my project. However when I build with Xcode 11.0 it reports 'file not found' and do not compile.

I believe the issue is somehow related to this commit and therefore is related to the issue #3218.

Here is an example project: https://github.com/Interfere/MalformedPod

[rafi-kamal]

@thomasvl

Which version of protobuf are you using?

[Interfere]

Version: v3.9.0 & v3.10.0
Language: Objective-C
Host OS: macOS Catalina ver. 10.15 (19A583)
Target OS: iOS 13.1.x
Compiler: Apple clang version 11.0.0 (clang-1100.0.33.8)

[thomasvl]

@paulb777

[thomasvl]

3.9.0 shouldn't have the change to the pod spec, so if you are saying you see it there, something else must be up.

[thomasvl]

https://github.com/Interfere/MalformedPod/blob/master/Podfile.lock#L16

COCOAPODS: 1.5.3

You appear to be using a pretty old version of cocoapods (May 2018); if you update your install do things work better? Your example seems to work fine for me with Cocoapods 1.8.4.

[Interfere]

I have updated the cocoapods. Still the same issue.

[thomasvl]

I have updated the cocoapods. Still the same issue.

Did you do a clean and pod install again so it could make changes to the projects?

Here's what I tried:

thomasvl@thomasvl-macbookpro:~/Desktop/testing$ git clone https://github.com/Interfere/MalformedPod.git
Cloning into 'MalformedPod'...
remote: Enumerating objects: 36, done.
remote: Counting objects: 100% (36/36), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 36 (delta 8), reused 36 (delta 8), pack-reused 0
Receiving objects: 100% (36/36), 11.53 KiB | 11.53 MiB/s, done.
Resolving deltas: 100% (8/8), done.
thomasvl@thomasvl-macbookpro:~/Desktop/testing$ cd MalformedPod/
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ pod install
Analyzing dependencies
Downloading dependencies
Installing Protobuf (3.10.0)
Generating Pods project
Integrating client project
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ xcodebuild -version
Xcode 11.1
Build version 11A1027
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ xcodebuild -quiet -workspace MalformedPod.xcworkspace -scheme MalformedPod -sdk iphonesimulator 
note: Using new build systemnote: Planning buildnote: Constructing build descriptionwarning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.1.99. (in target 'Protobuf' from project 'Pods')
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ 

[Interfere]

I have tried to build it with Xcode 11.0. Going to check it against newer version.

[thomasvl]

Xcode 11 worked fine also for me:

thomasvl@thomasvl-macbookpro:~/Desktop/testing$ git clone https://github.com/Interfere/MalformedPod.git
Cloning into 'MalformedPod'...
remote: Enumerating objects: 36, done.
remote: Counting objects: 100% (36/36), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 36 (delta 8), reused 36 (delta 8), pack-reused 0
Receiving objects: 100% (36/36), 11.53 KiB | 2.31 MiB/s, done.
Resolving deltas: 100% (8/8), done.
thomasvl@thomasvl-macbookpro:~/Desktop/testing$ cd MalformedPod/
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ pod install
Analyzing dependencies
Downloading dependencies
Installing Protobuf (3.10.0)
Generating Pods project
Integrating client project
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ xcodebuild -version
Xcode 11.0
Build version 11A420a
thomasvl@thomasvl-macbookpro:~/Desktop/testing/MalformedPod[master]$ xcodebuild -quiet -workspace MalformedPod.xcworkspace -scheme MalformedPod -sdk iphonesimulator 
note: Using new build systemnote: Planning buildnote: Constructing build descriptionwarning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.0.99. (in target 'Protobuf' from project 'Pods')

[Interfere]

interfere@MacBook-Pro-Alexey ~ $ rm -rf ~/Library/Caches/CocoaPods
interfere@MacBook-Pro-Alexey ~ $ git clone https://github.com/Interfere/MalformedPod.git
Cloning into 'MalformedPod'...
remote: Enumerating objects: 36, done.
remote: Counting objects: 100% (36/36), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 36 (delta 8), reused 36 (delta 8), pack-reused 0
Unpacking objects: 100% (36/36), done.
interfere@MacBook-Pro-Alexey ~ $ cd MalformedPod 
interfere@MacBook-Pro-Alexey ~/MalformedPod (master) $ pod install
Analyzing dependencies
Downloading dependencies
Installing Protobuf (3.10.0)
Generating Pods project
Integrating client project
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
interfere@MacBook-Pro-Alexey ~/MalformedPod (master) $ xcodebuild -version
Xcode 11.1
Build version 11A1027
interfere@MacBook-Pro-Alexey ~/MalformedPod (master) $ xcodebuild -quiet -workspace MalformedPod.xcworkspace -scheme MalformedPod -sdk iphonesimulator 
In file included from /Users/alexey.ushakov/MalformedPod/MalformedPod/AppDelegate.m:10:
In file included from /Users/alexey.ushakov/MalformedPod/Pods/Headers/Public/Protobuf/GPBProtocolBuffers.h:44:
/Users/alexey.ushakov/MalformedPod/Pods/Headers/Public/Protobuf/GPBWellKnownTypes.h:40:10: fatal error: 'protobuf/Any.pbobjc.h' file not found
 #import <protobuf/Any.pbobjc.h>
         ^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
note: Using new build systemnote: Planning buildnote: Constructing build descriptionwarning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 7.0, but the range of supported deployment target versions is 8.0 to 13.1.99. (in target 'Protobuf' from project 'Pods')
** BUILD FAILED **

UPD: Just a wild guess: could it be related to the new Apple case-sensitive filesystem flag?

interfere@MacBook-Pro-Alexey ~/MalformedPod (master) $ diskutil info /dev/disk0s2 
   Device Identifier:         disk0s2
   Device Node:               /dev/disk0s2
   Whole:                     No
   Part of Whole:             disk0

   Volume Name:               Not applicable (no file system)
   Mounted:                   Not applicable (no file system)
   File System:               None

   Partition Type:            Apple_APFS

[thomasvl]

The issue mentioned was for problems that used to happen from symlinks and how clang was dealing with things so it ended up seeing a different case. But it sorta sounds like you are seeing something different now, so the question is going to be what's different vs. what was seen before.

[Interfere]

I have just tried to build it on two different environments:

1. Compilation succeeds on case-insensetive APFS
2. Compilation fails on case-sensitive APFS

[thomasvl]

So the spec has module_name = 'protobuf', but it looks like your paths say Pods/Headers/Public/Protobuf so that actually seems to indicate the bug might be on the Cocoapods side where it is using the spec's name in one place instead of the module_name, and on case insensitive it works out. So it likely makes sense to open things up with a cocoapods issue as things aren't completely right there.

@paulb777 do you have any other ideas what could be done here?

[Interfere]

Seems cocoapods always puts public headers at 'Pods/Headers/Public/{Pod Name}/**' see ref

[Interfere]

Well, I solved my problem by placing the project at separate volume formated as case-insensetive APFS.

[mnemanja]

I don't think that is a long term solution @Interfere :)
I've tried all of the suggestions from this and other issues opened on this topic, and none worked for me, and it's always been some sort of hack or modifying the Podfile.

My colleague added the Firebase's Crashlytics, Analytics, Perf and App to our React native app and for him, it works fine, but for me, it breaks the build.

Mac Catalina 10.15.1
Pod version 1.5.2
@react-native-firebase/crashlytics 6.0.3

[paulb777]

@mnemanja Do you have the same problem that @Interfere reported? Are you using a case-sensitive file system with Protobuf 3.10.0 in the Podfile.lock?

[mnemanja]

@paulb777 that is correct. Same problem and case-sensitive system with Protobuf 3.10.0.

[paulb777]

A workaround is to add use_frameworks! to the Podfile.

It's not clear that it would be correct for CocoaPods to use the module_name for specifying the directory when the Podfile is choosing not to use modules.

[mnemanja]

I have tried using use_frameworks!, but that doesn't fix it.

[paulb777]

@mnemanja I get a successful build with use_frameworks! in the example attached above at https://github.com/Interfere/MalformedPod.

Please check that one and/or share an example that fails when use_frameworks! is in the Podfile.

[mnemanja]

@paulb777
When I run pod install with use_frameworks! I get the following message:

> pod install
Adding a custom script phase for Pod RNFBApp: [RNFB] Core Configuration
Adding a custom script phase for Pod RNFBCrashlytics: [RNFB] Crashlytics Configuration
Detected React Native module pods for RNCAsyncStorage, RNDeviceInfo, RNFBAnalytics, RNFBApp, RNFBCrashlytics, RNFBPerf, RNGestureHandler, RNLocalize, RNReanimated, RNSVG, and react-native-webview
Analyzing dependencies
Downloading dependencies
[!] The 'Pods-heatcontrol' target has transitive dependencies that include statically linked binaries: (/app/ios/Pods/Crashlytics/iOS/Crashlytics.framework and /app/ios/Pods/Fabric/iOS/Fabric.framework)

I've tried running the MalformedPod repo and it failed with a different error:

error: failed writing record 'utsname.h-7GU1UIJGG5QM': failed to rename '/Users/***/Library/Developer/Xcode/DerivedData/MalformedPod-bpticqbueuzuhagxzxjibprqpamd/Index/DataStore/v5/records/QM/utsname.h-7GU1UIJGG5QM-temp-d4ec308a' to '/Users/***/Library/Developer/Xcode/DerivedData/MalformedPod-bpticqbueuzuhagxzxjibprqpamd/Index/DataStore/v5/records/QM/utsname.h-7GU1UIJGG5QM': No such file or directory

Then I re-ran it and the first error was gone (I guess it created the necessary files) but the original error was there.

[paulb777]

@mnemanja The transitive dependency issue might be solved by restructuring the Podfile to move the Crashlytics target out of a dynamic framework target.

I'm not sure what's causing the difference for MalformedPod between you and me.

I plan to do investigation on the static library, case-sensitive file system use case, but it might not be for a few weeks - if no one else gets to it.

[mnemanja]

@paulb777 I would appreciate if you could point me in the right direction for this restructuring.
Thanks!

[paulb777]

A workaround is ln -s Protobuf protobuf in the Pods/Headers/Public directory.

[paulb777]

I'm not sure that there's a good CocoaPods solution, since CocoaPods documents adding the headers to a directory with the name of the pod - not the module.

Here's a post_install workaround for the Podfile:

post_install do
  system('cd Pods/Headers/Public; ln -s Protobuf protobuf')
end

[thomasvl]

What's the point of module_name then?

Seems like this goes back the original issue where we add the module_name maybe being the root problem, but was that issue in clang; like it resolved a symlink cocoapods made, and complained because that path ended up with the lower case even though the original link was upper case?

[paulb777]

module_name solves the issue in the use_frameworks! Podfile case, since the header gets found via the module. In the static library case, there are no modules, so it works fine on case insensitive file systems, but not in case sensitive file systems that require the pod name to be the right case.

[thomasvl]

I _think_ https://github.com/thomasvl/protobuf/tree/avoid_path_cases will actually fix this. It removed the use of a sub directory for the WKTs (prefixes the headers with GPB to avoid conflicts since the names can be sorta generic otherwise). The old names are shimmed just to avoid breaking folks, but if we go that route, we'll eventually remove the shims after giving folks a few releases to migrate.

If folks can give that a try and let me know how it goes, I can look at finishing landing it here for the next release.

[mikehardy]

Howdy folks, just cross-linking from the react-native-firebase repo issue so github's fancy cross-linking will show status at a glance there for future RNFB folks https://github.com/invertase/react-native-firebase/issues/2780