Closed fbp93 closed 4 months ago
I also checked and it's breaking starting from 0.74.0
@cipolleschi can you have a look when you have some time? thanks 🙏
Also getting this issue :'(
Looking into it. We probably make a mistake in configuring the RCTDeprecation podspec.
@fbp93 I tried the app and the main target builds fine with static libraries and static frameworks.
AudioManager fails, but it fails because React/RCTBridgeModule.h' file not found
, not RCTDeprecation
not found
I think that the problem is in the header search paths. If you look at the search paths for the main project, they look like this:
The header search paths of the AudioManager looks like this:
The structure of React-Core on disk is like this:
And, as you can see, there is no folder called Public
after Headers.
This type of setup, anyway, is not something we recommend: it would be better to create a proper pod for an external library, to benefit from all the automations we are building for autolinking.
That said, @fbp93 and @max-quirk, if you can provide a reproducer where I can see the RCTDeprecation.h file not found happen
, I'll be glad to dig into it more closely!
And, as you can see, there is no folder called Public after Headers.
@cipolleschi Shouldn't the header search path link to the headers in the pods? Because there I see the public folder. Have you been able to make the audio manager build by that change ? 🤔
This type of setup, anyway, is not something we recommend: it would be better to create a proper pod for an external library, to benefit from all the automations we are building for autolinking.
Unfortunatly I have a lots of them with the current setup, so it's not something I was plan to do immediatly, but I'll definitely consider it
Shouldn't the header search path link to the headers in the pods?
nope, because with frameworks, the items that are copied to the bundle and used for linking are the content of the .framework
folder.
Have you been able to make the audio manager build by that change ?
Unfortunately not, once I saw that the setup was not standard and the error was different, I stopped. I think we should first understand why we are seeing two different errors.
Unfortunatly I have a lots of them with the current setup, so it's not something I was plan to do immediatly, but I'll definitely consider it
😞 But I understand. Working with legacy projects is tough. I'm going to be on PTO next week, but I plan to resume the work on this when I'm back.
nope, because with frameworks, the items that are copied to the bundle and used for linking are the content of the .framework folder.
the weird thing is that the same setup was working fine with the previous react and even if I try to remove the public it's not working anyway 🤔
Unfortunately not, once I saw that the setup was not standard and the error was different, I stopped. I think we should first understand why we are seeing two different errors.
Actually it seems that sometimes I get your same error and sometimes the RCTDeprecation one, so I think it's kind of related. Probably if we are able to make it build we may fix both or understand more 🤔
@fbp93 any news on this?
In 0.73, we didn't have the RCTDeprecation
module, so that's probably why it was working.
@fbp93 I investigated this a little bit more.
First of all, my bad. I was trying to build with use_frameworks, but after reading the issue again, I can see that that was not the case.
Without frameworks, the search path you were using ($(SRCROOT)/../../ios/Pods/Headers/Public/React-Core
) is correct.
I added another search path there: $(SRCROOT)/../../ios/Pods/Headers/Public
.
and after that, it builds correctly.
The problem is that the Audio Manager was not finding the header in the available search paths.
Starting from Public
, the RCTDeprecation.h
header is in the path RCTDeprecation/RCTDeprecation.h
that is exactly the same import you have in the file.
This is not a standard and officially supported setup, so I don't think we can/should modify core to automate this. I hope this is enough to understand how these search paths work and to fix them forward for all the modules.
thanks! It seems working now (at least this building phase). I'll late you know if I have any other issue while migrating to the latest version. I'm gonna close the issue
@fbp93 How did you resolve the issue?
@fbp93 How did you resolve the issue?
I changed the header path as suggested in the above message
@fbp93 Any other steps you did? For me the issue is still reproducible even after those steps above with header change.
@dcisneros2 can you provide a reproducer for your project? @fbp93 project setup was quite different from the standard, so the solution that works for them might not be applicable to your case.
Hi! I am facing this issue when using use_frameworks! :linkage => :static
, the solution didn't work for me and my Pods/Headers doesn't have any RCTDeprecated file/folder
@Japoncio3k which version are you using?
Have you tried to re run yarn install
and pod install
? The folder has to be there.
If you can provide a reproducer, I can help out.
Yes, I am running on 0.74.5
I have already tried to delete node_modules
and yarn.lock
and used pod deintegrate
too
Will try to make a reproducer
I was able to fix this by removing use_frameworks! :linkage => :static
and adding :modular_headers => true
to pods that needed the use_frameworks!
Description
I'm trying to bump my project to React Native 0.74.2, but iOS is failing to compile due to the following issue:
This is happening only when I try to link a static library to my project which contains some object C code that imports React native. I reproduced the issue on a template project and tested with different versions:
Steps to reproduce
Perform the following commands:
React Native Version
0.74.2
Affected Platforms
Other (please specify)
Output of
npx react-native info
Stacktrace or Logs
Reproducer
https://github.com/fbp93/RN-0.74.2
Screenshots and Videos
No response