Diff in Podfile.lock when runs in different machines

franciscomorais commented 3 years ago

Description

When we run pod install we have different hashes in FBReactNativeSpec. This is because I think the building scripts are using full paths to generate the hash. For example, on the same machine if we rename the project directory, the hash will be different.

I think the PR that injects this bug is this.

Steps To Reproduce

1 - install node dependencies: yarn 2 - install ios pods dependencies: pod install 3 - create a commit in git: git commit -m "whatever your want" 4 - rename project folder: cd ../.. && mv projectSample projectSample2 && cd projectSample2/ios 5 - runs again pods installation command: pod install

Expected Results

Podfile.lock doesn't have diffs after run pod install --repo-update.

Founded Results

   ...
   FBLazyVector: 5776f027522ce1b2415982c48c8407c95966c60f
-  FBReactNativeSpec: 162f37a35ac13f9ef7ef0a77973a21393ba0dbab
+  FBReactNativeSpec: 7594b4ffdc73f2695967c9f7c766cf3c26da86a8
   Flipper: d3da1aa199aad94455ae725e9f3aa43f3ec17021
   ...

React Native version:

Module	Version
react	17.0.1
react-native	0.64.0-rc.4

github-actions[bot] commented 3 years ago

:warning:	Missing Environment Information
:information_source:	Your issue may be missing information about your development environment. You can obtain the missing information by running `react-native info` in a console.

github-actions[bot] commented 3 years ago

:warning:	Missing Required Fields
:information_source:	It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a new issue is created. Could you go back and make sure to fill out the template? You may edit this issue, or close it and open a new one.

madandrija commented 3 years ago

We have the same problem, each machine generates a different FBReactNativeSpec hash. @franciscomorais, please add your system info, here's mine

System:
    OS: macOS 11.2.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Memory: 1.99 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.15.4 - /usr/local/bin/node
    Yarn: Not Found
    npm: 6.14.10 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK:
      API Levels: 28, 29, 30
      Build Tools: 28.0.3, 29.0.2, 30.0.3
      System Images: android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.1 AI-201.8743.12.41.7042882
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_282 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1 
    react-native: 0.64.0-rc.4 => 0.64.0-rc.4 
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

franciscomorais commented 3 years ago

System info:

System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-9700F CPU @ 3.00GHz
    Memory: 7.74 GB / 64.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.20.0 - /usr/local/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.14.8 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK: Not Found
  IDEs:
    Android Studio: 4.1 AI-201.8743.12.41.7042882
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.5 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: 0.64.0-rc.4 => 0.64.0-rc.4
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

mlazari commented 3 years ago

I think the issue comes from here: https://github.com/facebook/react-native/blob/00bc09c8f76879eb1f9a92a6a643191da9355de8/scripts/react_native_pods.rb#L191

The object assigned to spec.script_phase contains some absolute paths (for example in srcs_dir), which I think affects the hash in Podfile.lock for FBReactNativeSpec. The issue was probably introduced even earlier, in this commit: https://github.com/facebook/react-native/commit/c901c1fbce080c6e9b6ed56dbccaa7f2fa0571b2#diff-43504ce3403645032fd1e42a7fe7a52171a9fbd0946229948e2c6abff3681120R58

martintreurnicht commented 3 years ago

The root cause of this is absolute pathing in script_phase, you can inspect the resolved spec file by running:

pod ipc spec node_modules/react-native/React/FBReactNativeSpec/FBReactNativeSpec.podspec

you should see something like:

{
  "name": "FBReactNativeSpec",
  "version": "0.64.0",
  "summary": "-",
  "homepage": "https://reactnative.dev/",
  "license": "MIT",
  "authors": "Facebook, Inc. and its affiliates",
  "platforms": {
    "ios": "10.0"
  },
  "compiler_flags": "-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1 -Wno-comma -Wno-shorten-64-to-32 -Wno-nullability-completeness",
  "source": {
    "git": "https://github.com/facebook/react-native.git",
    "tag": "v0.64.0"
  },
  "source_files": "**/*.{c,h,m,mm,cpp}",
  "header_dir": "FBReactNativeSpec",
  "pod_target_xcconfig": {
    "USE_HEADERMAP": "YES",
    "CLANG_CXX_LANGUAGE_STANDARD": "c++14",
    "HEADER_SEARCH_PATHS": "\"$(PODS_TARGET_SRCROOT)/React/FBReactNativeSpec\" \"$(PODS_ROOT)/RCT-Folly\""
  },
  "dependencies": {
    "RCT-Folly": [
      "2020.01.13.00"
    ],
    "RCTRequired": [
      "0.64.0"
    ],
    "RCTTypeSafety": [
      "0.64.0"
    ],
    "React-Core": [
      "0.64.0"
    ],
    "React-jsi": [
      "0.64.0"
    ],
    "ReactCommon/turbomodule/core": [
      "0.64.0"
    ]
  },
  "script_phases": {
    "name": "Generate Specs",
    "input_files": [
      "<absolute project path>/node_modules/react-native/scripts/../Libraries"
    ],
    "output_files": [
      "$(DERIVED_FILE_DIR)/codegen-FBReactNativeSpec.log",
      "<absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h",
      "<absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm"
    ],
    "script": "set -o pipefail\n\nbash -l -c 'SRCS_DIR=<absolute project path>/node_modules/react-native/scripts/../Libraries CODEGEN_MODULES_OUTPUT_DIR=<absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec CODEGEN_MODULES_LIBRARY_NAME=FBReactNativeSpec <absolute project path>/node_modules/react-native/scripts/generate-specs.sh' 2>&1 | tee \"${SCRIPT_OUTPUT_FILE_0}\"",
    "execution_position": "before_compile",
    "show_env_vars_in_log": true
  },
  "prepare_command": "mkdir -p <absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec && touch <absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h <absolute project path>/node_modules/react-native/scripts/../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm"
}

martintreurnicht commented 3 years ago

I've created a patch file that seems to solve the problem, i might have missed something but it seems to be working great for me and builds are passing, i had a look at the generated code output too and it seems to all be there. Could be cleaned up a bit but the main issue with the current approach is that $PODS_TARGET_SRCROOT is not accessible from prepare_command so the logic will have to be split for script_phase and prepare_command, but the good news is that the working directory for prepare_command is that of the pod, so it's pretty safe to just assume the relative path for that.

diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index 2a8affb..a807b2b 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -149,7 +149,7 @@ def use_react_native_codegen!(spec, options={})
   return if ENV['DISABLE_CODEGEN'] == '1'

   # The path to react-native (e.g. react_native_path)
-  prefix = options[:path] ||= File.join(__dir__, "..")
+  prefix = options[:path] ||= '$PODS_TARGET_SRCROOT/../../'

   # The path to JavaScript files
   srcs_dir = options[:srcs_dir] ||= File.join(prefix, "Libraries")
@@ -192,10 +192,12 @@ def use_react_native_codegen!(spec, options={})
     :name => 'Generate Specs',
     :input_files => [srcs_dir],
     :output_files => ["$(DERIVED_FILE_DIR)/codegen-#{codegen_modules_library_name}.log"].concat(generated_files),
-    :script => "set -o pipefail\n\nbash -l -c '#{env_vars} CODEGEN_MODULES_LIBRARY_NAME=#{codegen_modules_library_name} #{File.join(__dir__, "generate-specs.sh")}' 2>&1 | tee \"${SCRIPT_OUTPUT_FILE_0}\"",
+    :script => "set -o pipefail\n\nbash -l -c '#{env_vars} CODEGEN_MODULES_LIBRARY_NAME=#{codegen_modules_library_name} #{File.join("$PODS_TARGET_SRCROOT/../../scripts", "generate-specs.sh")}' 2>&1 | tee \"${SCRIPT_OUTPUT_FILE_0}\"",
     :execution_position => :before_compile,
     :show_env_vars_in_log => true
   }

-  spec.prepare_command = "#{mkdir_command} && touch #{generated_files.reduce() { |str, file| str + " " + file }}"
+
+
+  spec.prepare_command = "#{mkdir_command.sub prefix, '../../'} && touch #{generated_files.reduce() { |str, file| (str.sub prefix, '../../') + " " + (file.sub prefix, '../../') }}"
 end

now if you run pod ipc spec node_modules/react-native/React/FBReactNativeSpec/FBReactNativeSpec.podspec, you should see the following:

{
  "name": "FBReactNativeSpec",
  "version": "0.64.0",
  "summary": "-",
  "homepage": "https://reactnative.dev/",
  "license": "MIT",
  "authors": "Facebook, Inc. and its affiliates",
  "platforms": {
    "ios": "10.0"
  },
  "compiler_flags": "-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1 -Wno-comma -Wno-shorten-64-to-32 -Wno-nullability-completeness",
  "source": {
    "git": "https://github.com/facebook/react-native.git",
    "tag": "v0.64.0"
  },
  "source_files": "**/*.{c,h,m,mm,cpp}",
  "header_dir": "FBReactNativeSpec",
  "pod_target_xcconfig": {
    "USE_HEADERMAP": "YES",
    "CLANG_CXX_LANGUAGE_STANDARD": "c++14",
    "HEADER_SEARCH_PATHS": "\"$(PODS_TARGET_SRCROOT)/React/FBReactNativeSpec\" \"$(PODS_ROOT)/RCT-Folly\""
  },
  "dependencies": {
    "RCT-Folly": [
      "2020.01.13.00"
    ],
    "RCTRequired": [
      "0.64.0"
    ],
    "RCTTypeSafety": [
      "0.64.0"
    ],
    "React-Core": [
      "0.64.0"
    ],
    "React-jsi": [
      "0.64.0"
    ],
    "ReactCommon/turbomodule/core": [
      "0.64.0"
    ]
  },
  "script_phases": {
    "name": "Generate Specs",
    "input_files": [
      "$PODS_TARGET_SRCROOT/../../Libraries"
    ],
    "output_files": [
      "$(DERIVED_FILE_DIR)/codegen-FBReactNativeSpec.log",
      "$PODS_TARGET_SRCROOT/../../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h",
      "$PODS_TARGET_SRCROOT/../../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm"
    ],
    "script": "set -o pipefail\n\nbash -l -c 'SRCS_DIR=$PODS_TARGET_SRCROOT/../../Libraries CODEGEN_MODULES_OUTPUT_DIR=$PODS_TARGET_SRCROOT/../../React/FBReactNativeSpec/FBReactNativeSpec CODEGEN_MODULES_LIBRARY_NAME=FBReactNativeSpec $PODS_TARGET_SRCROOT/../../scripts/generate-specs.sh' 2>&1 | tee \"${SCRIPT_OUTPUT_FILE_0}\"",
    "execution_position": "before_compile",
    "show_env_vars_in_log": true
  },
  "prepare_command": "mkdir -p ../../React/FBReactNativeSpec/FBReactNativeSpec && touch ../../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h ../../React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm"
}

thaapasa commented 3 years ago

I have encountered this same problem and reported it here: https://github.com/facebook/react-native/issues/31193 (sorry, I did not find this issue report before). For me fixing the prefix in react_native_pods.rb works.

habovh commented 3 years ago

I'm encountering a a similar behaviour with glog and DoubleConversion. It seems their checksums also change when running pod install on a different machine. Both of these pods are also included in React Native, but are they all related to the FBReactNativeSpec? If not I can open a separate issue, but I thought it would make sense to mention it here anyway.

diff --git a/ios/Podfile.lock b/ios/Podfile.lock
index a27ec70a8..8ff577408 100644
--- a/ios/Podfile.lock
+++ b/ios/Podfile.lock
@@ -673,7 +673,7 @@ SPEC CHECKSUMS:
   boost-for-react-native: 39c7adb57c4e60d6c5479dd8623128eb5b3f0f2c
   BVLinearGradient: 0d985ec461359c82bc254f26d11008bdae50d17a
   CocoaAsyncSocket: 065fd1e645c7abab64f7a6a2007a48038fdc6a99
-  DoubleConversion: cde416483dac037923206447da6e1454df403714
+  DoubleConversion: 5805e889d232975c086db112ece9ed034df7a0b2
   FBLazyVector: 7b423f9e248eae65987838148c36eec1dbfe0b53
   FBReactNativeSpec: 976b4f05ee6cfd75377064c69875f5dd09bb992d
   FBSDKCoreKit: 4afd6ff53d8133a433dbcda44451c9498f8c6ce4
@@ -686,7 +686,7 @@ SPEC CHECKSUMS:
   Flipper-PeerTalk: 116d8f857dc6ef55c7a5a75ea3ceaafe878aadc9
   Flipper-RSocket: 127954abe8b162fcaf68d2134d34dc2bd7076154
   FlipperKit: 8a20b5c5fcf9436cac58551dc049867247f64b00
-  glog: 40a13f7840415b9a77023fbcae0f1e6f43192af3
+  glog: 1f3da668190260b06b429bb211bfbee5cd790c28
   libevent: 4049cae6c81cdb3654a443be001fb9bdceff7913
   libwebp: 946cb3063cea9236285f7e9a8505d806d30e07f3
   OneSignal: fa98eaa90372bb367b6a4a1c1622ffb9832c7600

mlazari commented 3 years ago

@habovh I use "react-native": "0.64.2" and only have this issue with FBReactNativeSpec.

The versions in Podfile.lock are:

- FBReactNativeSpec (0.64.2):

- DoubleConversion (1.1.6):

- glog (0.3.5)

habovh commented 3 years ago

@mlazari so my discrepancy probably comes from something else, I'll keep investigating. Thanks for making sure this issue was not related!

sonicdoe commented 3 years ago

@habovh I’ve been seeing DoubleConversion and glog in my diffs as well, which seems to be due to stale pods in the Pods directory. Removing them (rm -rf ios/Pods/{DoubleConversion,glog}) and re-running pod install resolves that issue for me.

habovh commented 3 years ago

@sonicdoe I've come to the same conclusion. However I fixed it by running pod update glog and pod update DoubleConversion, which then fetches the podspec from the React Native node_modules directory! A bit quicker than removing the whole Pods folder :)

gaberogan commented 3 years ago

@chrisglein What's the status on this?

Our team has been running into this issue, constantly ping-ponging Podfile.lock changes to each other. I realize users have submitted patch-package fixes but we would appreciate if these changes could actually be merged. Thanks

chrisglein commented 3 years ago

@chrisglein Chris Glein FTE What's the status on this?

No status drive by me - I've just been helping tag issues. I have no iOS expertise myself. But since there are a number of people hitting this let me see if I can flag the right folks to take a look.

mattijsf commented 3 years ago

Our team has it too. I haven't tried the patch-package from above yet assuming it would be patched pretty soon by the facebook team (as it is so easy to reproduce).

I hope this can be solved soon with a proper fix 🤞

jaredly commented 3 years ago

thanks @martintreurnicht , that worked for me! I applied it to the 0.64.2 release here, in case it helps anyone else. I'll probably make a PR against master soon. https://github.com/Khan/react-native/tree/fix-abspath

poiley commented 3 years ago

@jaredly any plans to open that PR soon? Sorry to nag -- this issue is blocking me on some personal projects.

mlazari commented 3 years ago

@jaredly any plans to open that PR soon? Sorry to nag -- this issue is blocking me on some personal projects.

If you can update RN to 0.65.1, this issue seems to be fixed in that version.

tijs commented 3 years ago

We still have this issue with the glog and DoubleConversion pods even after upgrading to RN 0.65.1. upgrading the pods will only help if everyone on the team keeps doing this I guess. But since the versions of these pods are not locked in the Podspecs I don't think this resolves anything. Would it be possible to lock the versions of these pods in the react native specs instead so that everyone downloads the same version automatically?

shamilovtim commented 3 years ago

Still experiencing this

shamilovtim commented 3 years ago

Fixed on 0.65.1, after rm -rf /Pods, pod cache clean --all and bundle exec pod install

chamaldesilva commented 2 years ago

0.64.2 still same issue

mcarlson commented 2 years ago

0.66.4 same issue

mattgabor commented 2 years ago

Still an issue with 0.66.2

dark1451 commented 2 years ago

0.64.2 same issue, Need to upgrade my react native version?

AdamGerthel commented 2 years ago

Just upgraded to 0.64.3 (latest Expo-compatible version) and got this issue.

MalinnaLeach commented 2 years ago

Still an issue with 0.67.2, and the patch above is out of date for this version

Mass812 commented 2 years ago

Having this issue as well 0.64.2

harryt04 commented 2 years ago

This issue makes it so that I can't cache my pods folder on Azure pipelines because the computed hash of my podfile.lock file at the end of the build is different than when it started.

eliw00d commented 2 years ago

I still get this from time to time and a "pod deintegrate" followed by a "pod install" usually fixes it for me. It's usually some combination of glog, RCT-Folly, and/or DoubleConversion. Most recently when I upgraded to 0.68.2.

mjfruits1 commented 2 years ago

In my case, there's a difference in authors' values. Here is the diff: screen_shot_2022-07-18_at_6 42 09_pm

Did you see it? One is a string, and another is an object. This difference in JSON makes a difference in the checksum.

ukasiu commented 1 year ago

For us it was the node minor version mismatch. Upgrading to newest node minor fixed the problem.

jaredly commented 1 year ago

fwiw this is fixed for me on react-native 0.66.4

sregg commented 1 year ago

This is still happening to us. RN 0.70.5 Only 1 dev out of 7 is changing the checksum but we couldn't find what was different with his machine. Same node version, same M1 machine with same OS version.

mlazari commented 1 year ago

@sregg Which one is the version of that 1 dev, the red or the green one? I use RN 0.71.3, I have the values on the right (green):

DoubleConversion: 5189b271737e1565bdce30deb4a08d647e3f5f54
glog: 04b94705f318337d7ead9e6d17c019bd9b1f6b1b

sregg commented 1 year ago

@sregg Which one is the version of that 1 dev, the red or the green one? I use RN 0.71.3, I have the values on the right (green):
DoubleConversion: 5189b271737e1565bdce30deb4a08d647e3f5f54
glog: 04b94705f318337d7ead9e6d17c019bd9b1f6b1b

That 1 dev is the one on the left. Everyone else is on the right like yours 🤔

vpetrykov commented 1 year ago

experiencing exactly the same issue with the 1:1 checksums differences. @sregg have you been able to resolve those differences? There are quite a few suggestions in this issue discussion (backported in 2021)

sregg commented 1 year ago

We never understood why that one dev had different checksums.

salla-andre commented 1 year ago

@vpetrykov @sregg I don't know if this is still an issue for you, but the problem is an update on the podspec files for glog and DoubleConversion that happened last year here.

The content have changed, but the version kept the same. Cocoapods caches those files when it resolves them from podspecs to Specifications (aka *.podspec.json). Your cache holds the old version copy of the transformed file (referencing iOS 11) and the other machine uses the new version (referencing iOS 12.4).

To fix this, you need to run a pod cache clean --all (or clean just those two dependencies like pod cache clean glog and removing all listed versions), a pod deintegrate to remove the Pods folder and references from your project (just deleting your Pods folder also works), and then running a pod install --repo-update. After doing this, if your repo holds the old versions hashes, upload your updated Podfile.lock.

vpetrykov commented 1 year ago

@AndreasLS , thanks for the suggestion ;) @sregg you can try to fix it in a similar way by cleaning pods caches

Shahaed commented 1 year ago

This specific issue should have been resolved with this commit: https://github.com/facebook/react-native/commit/751708d7798b57c9548684d152d5a3ccaf75b381

The issue could be closed.

matinzd commented 1 year ago

We've been scratching our heads for a while now, trying to figure out why our CI cache isn't cooperating. It appears that there's an inconsistency after installing pods on a different machine. Is this the only issue, or are there any specific pods that might be messing with the checksum stability?

Reeywhaar commented 11 months ago

Has the same three packages: DoubleConversion, boost and glog which differ on m1 and intel procs

--- a/ios/Podfile.lock
+++ b/ios/Podfile.lock
@@ -1106,10 +1106,10 @@ SPEC CHECKSUMS:
   Amplitude: 10f20d4436fdcd38ddd5be1da7033fcc21f4143e
   amplitude-react-native: 6e5b9e38c53e11a86f62f874a42cf176e2b82c86
   AnalyticsConnector: a53214d38ae22734c6266106c0492b37832633a9
-  boost: a7c83b31436843459a1961bfd74b96033dc77234
+  boost: 57d2868c099736d80fcd648bf211b4431e51a558
   BVLinearGradient: 880f91a7854faff2df62518f0281afb1c60d49a3
   CocoaAsyncSocket: 065fd1e645c7abab64f7a6a2007a48038fdc6a99
-  DoubleConversion: 831926d9b8bf8166fd87886c4abab286c2422662
+  DoubleConversion: 5189b271737e1565bdce30deb4a08d647e3f5f54
   FBLazyVector: 5fbbff1d7734827299274638deb8ba3024f6c597
   FBReactNativeSpec: 638095fe8a01506634d77b260ef8a322019ac671
   Firebase: 414ad272f8d02dfbf12662a9d43f4bba9bec2a06
@@ -1132,7 +1132,7 @@ SPEC CHECKSUMS:
   Flipper-PeerTalk: 116d8f857dc6ef55c7a5a75ea3ceaafe878aadc9
   FlipperKit: 2efad7007d6745a3f95e4034d547be637f89d3f6
   fmt: ff9d55029c625d3757ed641535fd4a75fedc7ce9
-  glog: 5337263514dd6f09803962437687240c5dc39aa4
+  glog: 04b94705f318337d7ead9e6d17c019bd9b1f6b1b
   GoogleAppMeasurement: 70ce9aa438cff1cfb31ea3e660bcc67734cb716e
   GoogleDataTransport: 54dee9d48d14580407f8f5fbf2f496e92437a2f2
   GoogleUtilities: 0759d1a57ebb953965c2dfe0ba4c82e95ccc2e34

mlazari commented 11 months ago

@Reeywhaar If you try to remove pod caches and reinstall pods on both computers, does it fix the issue?

mihai@Mihais-Mac-mini ios % rm -rf ~/Library/Caches/CocoaPods
mihai@Mihais-Mac-mini ios % rm -rf ~/.cocoapods
mihai@Mihais-Mac-mini ios % rm -rf Pods                              
mihai@Mihais-Mac-mini ios % pod install

Reeywhaar commented 11 months ago

Nope, no luck, tried updating said pods, install with repo-update, update with repo-update, cleaning cache with pod cache clean %podname% --all.

Reeywhaar commented 11 months ago

I've also found someone in google with exact same hashes for boost, glog and DoubleConversion, which means it is not some per-machine hash:

https://gitlab.ow2.org/RocketChat/Rocket.Chat.ReactNative/-/blob/5e8e359fa8d9f48d9207c2256fff9524aa231e74/ios/Podfile.lock https://github.com/callstack/react-native-pager-view/blob/master/example/ios/Podfile.lock

mlazari commented 11 months ago

@Reeywhaar I have the same hashes as the green ones in your example on my Mac Mini with M1:

boost: 57d2868c099736d80fcd648bf211b4431e51a558
DoubleConversion: 5189b271737e1565bdce30deb4a08d647e3f5f54
glog: 04b94705f318337d7ead9e6d17c019bd9b1f6b1b

Reeywhaar commented 11 months ago

Indeed! Updating pods on m1 resolved the issue. Now I have correct hashes (e.g 57d286 for boost). My problem was because I thought hashes on m1 were correct because I did install there last. @mlazari Thank you for the enlightenment!

stianjensen commented 11 months ago

The general problem with glog, DoubleConversion etc. is simply that their podspecs are often updated without bumping the version number at the same time. The hashes in your podfile is a checksum of that package's podspec file, which cocoapods only expects to change when its version number changes. This confuses cocoapods, so you need to explicitly update these packages to be able to get the correct new hash when updating react-native.

In our project we just have a permanent list of some packages to always call update on when resolving new versions (just make sure to also not run this update command on CI, where you want to only install from your lockfile).

Our Makefile pod install target is basically this:

ifeq ($(CI), true)
  POD_INSTALL_ARGS := --deployment
endif

install:
  ifneq ($(CI),true)
      cd ios && bundle exec pod update glog RCT-Folly DoubleConversion boost hermes-engine
  endif
      cd ios && bundle exec pod install ${POD_INSTALL_ARGS}

facebook / react-native