React-native-screens: Undefined symbol: _OBJC_CLASS_$_RCTImageLoader

[khasbilegt]

Description

Build fails on react-native-screens versions 2.18.0, 2.18.1 but works fine on previous versions.

Screenshots

Steps To Reproduce

1. yarn upgrade react-native-screens@latest
2. yarn pod
3. xcode build

Expected behavior

Successful Xcode build

Actual behavior

Failed Xcode build

Package versions

• React: v16.13.1
• React Native: v0.63.4
• React Native Screens: v2.18.1

[WoLewicki]

Can you reproduce this issue on the fresh react-native project? If no, it can be an issue of wrong transition between the react-native versions in your project. cc @jakmak24 since you had same problem.

[jakmak24]

@khasbilegt Hi. I've experienced a similar issue and it was related to using use_frameworks! in Podfile.
Try adding the following step to your Podfile:

  pre_install do |installer|
    installer.pod_targets.each do |pod|
      if pod.name.eql?('RNScreens')
        def pod.build_type
          Pod::BuildType.static_library
        end
      end
    end
  end

[kesha-antonov]

pre_install do |installer|
installer.pod_targets.each do |pod|
if pod.name.eql?('RNScreens')
def pod.build_type
Pod::BuildType.static_library
end
end
end
end

thanks, it helped!

[shariqsami]

@jakmak24 its causing this error

ld: warning: directory not found for option '-L-L/Users/apple/apps/appElection/ios/Build/Products/Debug-iphonesimulator/RNScreens'
ld: library not found for -lRNScreens
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[phuchungnguyen78]

I got the same issue with @khasbilegt , try to add some codes as jakmak24's suggestion, but it doesn't work.
I created react native project with salesforce mobile SDK (https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/react_native_new_project.htm)

[Daniel0liver]

Does anyone know how to explain why this happens? I'm doing the integration of react native with the existing ios app and I'm having this same problem in the x86_64 architecture not only in lib react-native-screens but also in react-native-masked-view and react-native-svg

xcode: 12.4v
react-native: 0.63.4v

[gmapnl]

Exactly same issue, pre_install not helps

tried to add s.static_framework = true in RNScreens.podspec instead, without success.

Xcode : 12.4
React: v17.0.1
React Native: v0.64.0
React Native Screens: v2.18.1

[sujith-surendranath]

@phuchungnguyen78 did you find any solution for salesforce SDK + RN projects?

[WoLewicki]

If the change suggested by @jakmak24 doesn't work for you, you can always revert the commit that introduces this change: https://github.com/software-mansion/react-native-screens/pull/768 with e.g. patch-package.

[Jalil-Irfan]

@khasbilegt Hi. I've experienced a similar issue and it was related to using use_frameworks! in Podfile.
Try adding the following step to your Podfile:

  pre_install do |installer|
    installer.pod_targets.each do |pod|
      if pod.name.eql?('RNScreens')
        def pod.build_type
          Pod::BuildType.static_library
        end
      end
    end
  end

Thanks it helped me by pass the issue but I would like to know the actual fix and also I would like to know what issues i can expect in future because of this pod file change

[sunzhongliangde]

Sorry, I don't have this problem. Is there anyone else? Is there any problem using this version in a new project?

[flash76]

Sorry, I don't have this problem. Is there anyone else? Is there any problem using this version in a new project?

@sunzhongliangde I'm using it in my project, and adding the pre install action to build RNScreens as a static library causes
Cycle inside FBReactNativeSpec; building could produce unreliable results. This usually can be resolved by moving the shell script phase '[CP-User] Generate Specs' so that it runs before the build phase that depends on its outputs.

[gmapnl]

Sorry, I don't have this problem. Is there anyone else? Is there any problem using this version in a new project?

@sunzhongliangde I'm using it in my project, and adding the pre install action to build RNScreens as a static library causes
Cycle inside FBReactNativeSpec; building could produce unreliable results. This usually can be resolved by moving the shell script phase '[CP-User] Generate Specs' so that it runs before the build phase that depends on its outputs.

It's another problem. Fixed for me with :

post_install do |installer|
  react_native_post_install(installer)

  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'
    end

    if (target.name&.eql?('FBReactNativeSpec'))
      target.build_phases.each do |build_phase|
        if (build_phase.respond_to?(:name) && build_phase.name.eql?('[CP-User] Generate Specs'))
          target.build_phases.move(build_phase, 0)
        end
      end
    end
  end
end

[WoLewicki]

I will close this issue since it is not react-native-screens specific and the solutions are already listed. Please comment here if something is wrong and we can reopen it then.

[flash76]

@khasbilegt Hi. I've experienced a similar issue and it was related to using use_frameworks! in Podfile.
Try adding the following step to your Podfile:

  pre_install do |installer|
    installer.pod_targets.each do |pod|
      if pod.name.eql?('RNScreens')
        def pod.build_type
          Pod::BuildType.static_library
        end
      end
    end
  end

I was also having this issue and I _think_ I was able to fix it a bit more elegantly. Instead of doing use_frameworks! and putting pre-install directives, I used CocoaPods User-Defined Build Types and added :build_type => :dynamic_framework to the dependencies that required use_frameworks!.

[billnbell]

Sorry, I don't have this problem. Is there anyone else? Is there any problem using this version in a new project?

@sunzhongliangde I'm using it in my project, and adding the pre install action to build RNScreens as a static library causes
Cycle inside FBReactNativeSpec; building could produce unreliable results. This usually can be resolved by moving the shell script phase '[CP-User] Generate Specs' so that it runs before the build phase that depends on its outputs.

It's another problem. Fixed for me with :

post_install do |installer|
  react_native_post_install(installer)

  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'
    end

    if (target.name&.eql?('FBReactNativeSpec'))
      target.build_phases.each do |build_phase|
        if (build_phase.respond_to?(:name) && build_phase.name.eql?('[CP-User] Generate Specs'))
          target.build_phases.move(build_phase, 0)
        end
      end
    end
  end
end

I am using

target 'TheClub' do
  config = use_native_modules!

  use_react_native!(
    :path => config[:reactNativePath],
    # to enable hermes on iOS, change `false` to `true` and then install pods
    :hermes_enabled => true
  )

  target 'TheClubTests' do
    inherit! :complete
    # Pods for testing
  end

  # Enables Flipper.
  #
  # Note that if you have use_frameworks! enabled, Flipper will not work and
  # you should disable these next few lines.

  if !ENV['CI']
    use_flipper!({ 'Flipper' => '0.79.1' })

    post_install do |installer|
      flipper_post_install(installer)
      installer.pods_project.targets.each do |t|
        t.build_configurations.each do |config|
          config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '11.0'
        end
      end
    end
  end
end

How do I fix it?

[louishwh]

post_install do |installer|

react_native_post_install(installer)

installer.pod_targets.each do |pod|
  if pod.name.eql?('RNScreens')
    def pod.build_type
      Pod::BuildType.static_library
    end
  end

  if pod.name.eql?('RNCMaskedView')
    def pod.build_type
      Pod::BuildType.static_library
    end
  end
end

installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
        config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '10.0'
        config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'
    end

    if (target.name&.eql?('FBReactNativeSpec'))
         target.build_phases.each do |build_phase|
        if (build_phase.respond_to?(:name) && build_phase.name.eql?('[CP-User] Generate Specs'))
            target.build_phases.move(build_phase, 0)
        end
      end
    end
end

end

[markwilcox]

I've just run into this issue today after upgrading react-native-screens. I'm working on a complex hybrid native/react-native app with use_frameworks!. I've seen similar issues on other React Native modules with native code too. It's a question of build timing luck, because RNScreens.podspec has a missing dependency. Adding a new pod, or updating a pod can cause this to start failing, or be magically fixed again. The RNScreens pod is trying to be linked before the React-RCTImage pod has been compiled, hence the missing symbol at link time.

When everyone shifted from depending on 'React' to 'React-Core' because Xcode got fussy about that, some packages that depend on bits of React Native outside 'React-Core' have not added all those frameworks explicitly.

Form me adding:
s.dependency "React-RCTImage"
to RNScreens.podspec fixes this issue. Although it would be worth double-checking what classes from React Native are actually used and which modules they're in to make sure all the dependencies are captured, because otherwise it's just luck what gets built in what order in each project.

I hope that all makes sense and it would be great if this could be fixed in a future release @WoLewicki :pray: - then I can remove my package patch.

[WoLewicki]

@markwilcox so could you make a PR with such a change and link it here for people to be able to test it and say if it resolves their issue? It would be great if we could resolve this issue by it.

[markwilcox]

I double checked the dependencies and it was only "React-RCTImage" that was missing. This gets our build through CI without any of the messy local podfile hacks suggested above. Made a PR - linked above. It shouldn't have any effect on users that don't have the error, you're just declaring your dependency on something that would get built anyway to ensure the correct build order.