-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure to archive with new build system, extensions, and subspec combinations #8206
Comments
I've the exact same issue with multiple targets that use different iOS versions (10.0 & 12.0)
@paulb777 Did you manage to fix this issue? |
@tomspee So far, I only have the workaround of changing the Podfile so that extensions don't use a different subset of subspecs that the app. Your issue may be different - same symptom, but different cause. |
I have the same issue. I think the reason that there are duplicate frameworks could be because there are multiple projects in the same workspace. It appears to be due to how the naming works when creating frameworks. We have a dependency
We have a separate dependency Because This causes our workspace to have a collision with two frameworks named: Note that these are in two separate projects but compiling down into one app. |
I've been testing for a while and I've created an empty project with just 2 targets, one main project and one widget. In the Podfile both targets (with different platforms, iOS 10 & 12) use just one shared pod, Alamofire. Also then I'm getting the same errors. @vinceis1337 Do you have a solution/workaround? |
@tomspee Workaround is to specify subspec explicitly i.e.
This causes the build product path to always have the subspec name (in this example Hmm..this might not work for you though because I don't think Alamofire has subspecs does it? Could you post the error logs? |
Same problem here. Even though the targets contain the subspec names ( |
Yep. I'm seeing this in our project using a pod with multiple sub-specs referenced from different targets. This is a show stopper... 1.6.0.beta.2.
Please note the suggested workaround gives no relief. Additionally, I have a lot of related warnings coming from the build system. Notably
|
Any progress on this? |
This issue seems related to #7733 where @segiddins says "CocoaPods can only embed a single framework with a given name, so you're not able to expose different functionality to the extension and the main app by using subspecs". However, this issue is different since these examples work fine with the old build system. |
I'm working on a fix to make sure that an extension target's pod targets include the subspec combinations of its host app. |
I got a fix working for the basic case of directly depending upon different subspec combinations. However, I'm not sure what to do about the case where the subspec combination is coming transitively via another target. It doesn't seem right to try to change that other target. I'm starting to think that subspecs are not scalable for source pods, since they imply different variations of the same named library could be needed and different variations of the same-named library does not work well with the Xcode builder and loader. Should CocoaPods be change or have an option to build a different library for each subspec? |
I think we need to rethink subspecs entirely in 2.x. |
Here's an update from my ongoing investigation: For subspecs from dynamic frameworks pods, there could have easily been load failures with the old build system depending on which subspec combination got copied into the app's Frameworks folder and which symbols are being used from which targets. For any workspace that ends up with different subspec combinations between an extension and the host app, it should be possible to make it fail at load time by calling methods from subspec combination that didn't get copied to the bundle. Therefore, it is arguable that the new archive failure is a good thing - although it would be much better for the build system to give the error - or at least a warning - in a regular build instead of waiting until archiving to expose it. For subspecs from static frameworks pods, regular builds with the old and new build systems should always work fine because the right frameworks are built into appropriately labeled directory and properly linked into the right build targets. It doesn't matter which frameworks are copied into the bundle since static frameworks are linked at build time and not needed at load time. The issue with the new build system is that the archiver wants to put all intermediate frameworks into the same directory instead of separate directories for each build target like the regular builder. I'm thinking about flushing this out a bit further and sending a Radar.
|
The issue is still present in 1.6.0-rc1, the only solution for me was to switch back to the old build system. |
I hope Apple fix that soon. |
Yeah I'm running into this. We have two different google pods included. One requires Not exactly sure what to do about this. Any other workarounds? |
Maybe I'm misreading, but changing |
Yeah, you are exactly right. That's what I determined. Unfortunately I can't fix that without a bunch of PRs to various google pods or hosting a pod spec for it locally. |
@sprynmr You should be able to add |
I can add their targets to my Podfile and override their podspec? To be clear, we include a couple google dependencies, which in turn include either |
CocoaPods will union the dependencies from all the requested podspecs in the target of the Podfile, so you can explicitly add 'GTMSessionFetcher/Full', so that all of your targets end up matching the GTMSessionFetcher subspec subset. |
Aha! I had tried that, and it didn’t work, so I looked closer. Turns out we also had Thanks for the help! |
@lifely I tried your script but it is not working. I am getting the following error while trying to distribute. Not sure what I am missing.
If you could give a cocoapods-plugin I could try that way as well. |
It seems it doesn't found the correct path of the binary.
can you check or upload the archive.plist here, what's the path given in the applicationProperti attribute ? |
I've run into this same problem, albeit from a slightly different perspective. I'm developing a framework, and have two versions (
The
Note that the |
I had the same problem and solved it like this: Add the problematic package EXPLICITLY for EACH target. Let's say the error message complains about 'GTMSessionFetcher'. The likely reason is that you have multiple targets that have pods that are dependent on GTMSessionFetcher. The problem is solved if you add: pod 'GTMSessionFetcher' To each target. |
@winstonschen I am not sure if this solution is right or wrong but it works! |
I am getting this error as well, xcode v13.31 on a project I 'inherited'. SDWebImage-Core-GIF and SDWebImage.default-gif both create the SDWebImage.framework, stopping me from archiving. I read through all the replies but I didn't manage to make it work with any of the solutions proposed. Anyone got SDWebImage to work? |
谢谢您,文件 王锦发 已收到。
|
Happy New Year! 2023, issue still there btw... |
谢谢您,文件 王锦发 已收到。
|
I got this error in my Flutter 3.3 app on iOS after adding Firebase Analytics & Performance. The only way to fix it was in this previous answer: Adding |
nicely done!! |
In my case, this helped me! Thanks! |
Maybe something worth noting.. When i add this I set the deployment target both to 14.0, and tried a few things but this all didn't made the fix, other than duplicating the google utilities in both targets. But maybe a hint to understand why it creates duplicate pods. idk. |
|
I am also getting same type of issue while creating archive , any solution for this Showing Recent Issues Prepare build Multiple commands produce '/Users/aurus/Library/Developer/Xcode/DerivedData/Onference-cgoqpazsojiiyzdibeqgwomjirbt/Build/Intermediates.noindex/ArchiveIntermediates/Onferenc |
Samehere, also having the same issue when creating archive |
hi, just want to check if anyone has found a resolution on this? |
Hi, i am also getting same error, any solution? |
Same for me but with
I get the same error when I revert to 2.0.4 when PrivacyInfo.xcprivacy wasn't added yet. |
🌈
Report
What did you do?
Product -> Archive
What did you expect to happen?
Successful archive
What happened instead?
CocoaPods Environment
Also occurs with 1.6.0
Stack
Installation Source
Plugins
Podfile
Project that demonstrates the issue
https://github.com/paulb777/NewBuildExtensionSubspec
Likely a direct result of creating two build targets for the GTMSessionFetcher CocoaPod:
The text was updated successfully, but these errors were encountered: