Xcode 14.3 has pod lib lint fail

[groue]

• I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Hello,

I ran pod lib lint GRDB.swift.podspec --allow-warnings --verbose from a fresh clone of https://github.com/groue/GRDB.swift/tree/v6.10.1, with Xcode 14.3 (14E222b)

What did you expect to happen?

A success, as with Xcode 14.2. And if pod lib lint succeeds, I can expect pod trunk push to succeed as well.

What happened instead?

An error, unlike Xcode 14.2. And since pod lib lint fails, I'm pretty sure pod trunk push will fail as well: I can't publish new GRDB podspecs with Xcode 14.3.

Relevant lines from the output of the command:

...
    ld: file not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    
    /var/folders/dp/2xq7_lgj7k5fdnl5xm0s126r0000gn/T/CocoaPods-Lint-20230401-1982-y8jwp9-GRDB.swift/Pods/Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.9, but the range of supported deployment target versions is 10.13 to 13.3.99. (in target 'SQLCipher' from project 'Pods')
    ** BUILD FAILED **
...
   Testing with `xcodebuild`. 
 -> GRDB.swift (6.10.1)
    - NOTE  | [GRDB.swift/standard,GRDB.swift/SQLCipher] xcodebuild:  note: Using codesigning identity override: -
    - NOTE  | [GRDB.swift/standard,GRDB.swift/SQLCipher] xcodebuild:  note: Building targets in dependency order
    - NOTE  | [GRDB.swift/standard,GRDB.swift/SQLCipher] xcodebuild:  note: Metadata extraction skipped. No AppIntents.framework dependency found. (in target 'GRDB.swift' from project 'Pods')
    - NOTE  | [GRDB.swift/standard,GRDB.swift/SQLCipher] xcodebuild:  note: Metadata extraction skipped. No AppIntents.framework dependency found. (in target 'App' from project 'App')
    - NOTE  | [GRDB.swift/standard,GRDB.swift/SQLCipher] xcodebuild:  note: Using codesigning identity override: 
    - ERROR | [GRDB.swift/SQLCipher] xcodebuild: Returned an unsuccessful exit code.
    - NOTE  | [GRDB.swift/SQLCipher] xcodebuild:  clang: error: linker command failed with exit code 1 (use -v to see invocation)
    - NOTE  | [iOS] [GRDB.swift/SQLCipher] xcodebuild:  Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'SQLCipher' from project 'Pods')
    - NOTE  | [OSX] [GRDB.swift/SQLCipher] xcodebuild:  Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.9, but the range of supported deployment target versions is 10.13 to 13.3.99. (in target 'SQLCipher' from project 'Pods')
    - NOTE  | [watchOS] [GRDB.swift/SQLCipher] xcodebuild:  Pods.xcodeproj: warning: The watchOS Simulator deployment target 'WATCHOS_DEPLOYMENT_TARGET' is set to 2.0, but the range of supported deployment target versions is 4.0 to 9.4.99. (in target 'SQLCipher' from project 'Pods')
    - NOTE  | [tvOS] [GRDB.swift/SQLCipher] xcodebuild:  Pods.xcodeproj: warning: The tvOS Simulator deployment target 'TVOS_DEPLOYMENT_TARGET' is set to 9.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'SQLCipher' from project 'Pods')

[!] GRDB.swift did not pass validation, due to 1 error.
You can use the `--no-clean` option to inspect any issue.

A Google search for linker error with Xcode 14.3 and libarclite_macosx.a found this page. It looks like the problem is a wrong deployment target.

The log indeed warns:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.9, but the range of supported deployment target versions is 10.13 to 13.3.99. (in target 'SQLCipher' from project 'Pods')

But the podspec mentions '10.13' as the macOS deployment target:

  s.ios.deployment_target = '11.0'
  s.osx.deployment_target = '10.13'
  s.watchos.deployment_target = '4.0'
  s.tvos.deployment_target = '11.0'

I don't know how to fix this error.

CocoaPods Environment

Stack

   CocoaPods : 1.12.0
        Ruby : ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22]
    RubyGems : 3.4.5
        Host : macOS 13.3 (22E252)
       Xcode : 14.3 (14E222b)
         Git : git version 2.39.2 (Apple Git-143)
Ruby lib dir : /opt/homebrew/Cellar/ruby/3.2.2/lib
Repositories : trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /opt/homebrew/lib/ruby/gems/3.2.0/bin/pod

Plugins

cocoapods-deintegrate : 1.0.5
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.1
cocoapods-trunk       : 1.6.0
cocoapods-try         : 1.2.0

Project that demonstrates the issue

https://github.com/groue/GRDB.swift/tree/v6.10.1

[RoqueCampos]

I’m having the same issue, would be very glad if we had a fix. Thank you.

[Coedice]

At a glance, this looks like it's the same problem as #11828, though I'm not sure. If it is the same, I recommend you subscribe to that issue for further updates.

[groue]

At a glance, this looks like it's the same problem as #11828, though I'm not sure. If it is the same, I recommend you subscribe to that issue for further updates.

Thanks @Coedice,

According to this answer, it's not quite a problem of path resolution, but rather a problem that the CocoaPods build looks for libarclite_macosx.a in the first place.

Maybe fixing #11828 would fix this issue as a side-effect. But the root problem remains: minimum targets in the podspec are not honored, and libarclite_macosx.a is not supposed to be necessary.

[paulb777]

This particular issue could be addressed by the GRDB dependency, https://github.com/CocoaPods/Specs/blob/master/Specs/1/2/7/SQLCipher/4.5.3/SQLCipher.podspec.json#L9, updating its minimum platform versions to at least iOS 9, etc.

[groue]

Well, it's not possible to modify a podspec that has been published. Also, I'm not going to ask the SQLCipher team to publish a new release just to test this hypothesis. And even if they would, bumping the minimum SQLCipher version supported by GRDB would be an important breaking change that I'd prefer to avoid.

[paulb777]

@groue I would say that it's more arguable to be an Xcode bug since Xcode is trying to link for a target without providing the library.

On the other hand, it's arguable that CocoaPods' podspecs should still be claiming support for iOS versions that Xcode hasn't supported for years.

We've addressed this issue for our CocoaPods clients by publishing patch updates of our podspecs without changing the library. For example, see firebase/leveldb-library-podspec#12 which addresses this issue for a Firebase dependency.

While it's a breaking change in theory, it's not in practice, since the app store does not accept apps from Xcode versions that support those platform versions.

In the meantime, CocoaPods clients can work around with a post_install script like https://stackoverflow.com/a/75729977/556617

[groue]

@paulb777 I don't understand what you are trying to tell, and why it looks like you are trying to minimize this issue. Are your telling I should close the issue and report the problem to Apple?

This won't work, because Apple won't do anything. This issue is a CocoaPods problem, because it does not honor the specified minimum target. I'm doing my part of the job by providing correct minimum targets in the podspec given to pod lib lint (and pod trunk push). Cocoapods does not. It just happens that Xcode 14.3 no longer supports a behavior that was wrong in the first place.

Besides, CocoaPods clients are out of the frame of this issue. No one can "fix" one's Podfile if a library could not be published with pod trunk push in the first place (and that's in the frame of this issue).

I understand that you are happy with your workaround. And I'm happy for you. But it would be much better if CocoaPods itself would address the issue globally, instead of forcing each individual library maintainers to perform duplicated workarounds. And in my particular case, there's nothing I can do. That's why this issue remains open, until a proper answer acknowledges that there's a problem. I'll then help figuring out a solution if I can.

[paulb777]

I'll try another framing:

The GRDB.podspec is choosing to use a dependency that claims support for macOS 10.9. CocoaPods follows the wishes of the GRDB podspec and builds a project targeting macOS 10.9. Xcode 14.3 fails to build the resulting project because it doesn't support macOS 10.9 targets.

I agree with you that it would be nice for CocoaPods to do as much as possible to help libraries evolve as Apple evolves its tools and deprecates old platforms. While I continue to be impressed with how much CocoaPods does with only volunteers, there are limits.

Xcode has been warning for a few years now about macOS 10.9 not being supported and podspecs have had plenty of time to update to address the Xcode platform requirements.

[groue]

I'll try another framing:

The GRDB.podspec is choosing to use a dependency that claims support for macOS 10.9.

Yes.

CocoaPods follows the wishes of the GRDB podspec and builds a project targeting macOS 10.9.

I disagree: GRDB restricts the minimum target to more recent OSes in its own podspec. There is no point building for macOS 10.9 when GRDB requires 10.13+ (the same of other platforms). Not only there is no point building for macOS 10.9, but:

Xcode 14.3 fails to build the resulting project because it doesn't support macOS 10.9 targets.

We are in full agreement there.

[paulb777]

It wouldn't be correct for CocoaPods to build dependencies for newer versions than the dependency itself specifies since they could be using APIs that have been deprecated, deleted or changed after that specified version.

[groue]

You put a "maximum" in your interpretation of "minimum target", and this interpretation creates this issue, for no good reason.

With this interpretation, CocoaPods automatically and unavoidably breaks perfectly fine libraries, as time goes by.

This interpretation ignores that libraries can use availability checks in order to avoid the api changes you describes. It's not because a library claims support iOS N that it can't build on iOS N+1. Heck, we do this every day.

It's not because a library could be using removed APIs that CocoaPods is allowed to break the build. This is just artificial churn that no one is asking for.

That's why, once again, this issue is still not closed. 🙂

[Ariflo]

Same issue here. Thanks for posting.

[agruchala]

Hi, new version is out, but it doesn't fix problem with Xcode 14.3. Does someone know any workaround we can do to temporarily bypass this issue?
Is there plan to fix linting on Xcode 14.3?

[anton-plebanovich]

In my case, libarclite_iphoneos.a was missing. I have a dependency in my pod spec on a framework that will likely not be updated.
Workaround solution: https://stackoverflow.com/a/75920796/4124265

[agruchala]

In my case, libarclite_iphoneos.a was missing. I have a dependency in my pod spec on a framework that will likely not be updated.

Workaround solution: https://stackoverflow.com/a/75920796/4124265

This is not good solution, since using any cloud based CI will require doing it for every build. Also copying some files from external repo can be malicious.

[anton-plebanovich]

This is not good solution, since using any cloud based CI will require doing it for every build. Also copying some files from external repo can be malicious.

I agree, just had to publish my spec with minimum time spent. Another possibility is to revert Xcode to 14.2 I guess.

[paulb777]

A workaround for some of our other Xcode 14.3 pod spec lint failures is to add unit_tests.requires_app_host = true to test_specs that didn't need that option with Xcode 14.2.

[ykhandelwal913]

we are facing the same issue. Any workaround for the same to work for xcode 14.3?

[adrian-niculescu]

Related: #11895 Publication of Pods that have dependencies targeting iOS < 11 is also broken.

So far all workarounds discussed here are applicable for apps, not for Pod authors, so pod linting and pod publication are still blocked.

[zhuozhuo]

Same issue here. Thanks for posting.

[bnickel]

It wouldn't be correct for CocoaPods to build dependencies for newer versions than the dependency itself specifies since they could be using APIs that have been deprecated, deleted or changed after that specified version.

Can you expand on this? My understanding is that the offending deployment_target property sets {PLATFORM}_DEPLOYMENT_TARGET, but SDKROOT is always the latest SDK version. Building for latest will already cause failures if APIs have been changed or deleted, since the compiler does its validation based on that Apple uses the SDK version at the app level to special case behavior for old apps. I think all that deployment target gets you is silencing deprecation warnings and specifying what versions you support for the App Store, again at the app level.

Is there something I'm missing?

[groue]

@bnickel, I don't understand your question. Everything is said in the issue description.

To sum up: a podspec specifies some minimum deployment targets. Those are not honored by pod lib lint and pod trunk push, that use a lower deployment target. This lower deployment target triggers build errors with Xcode 14.3, and it is 99% expected that those errors would be fixed if the minimum deployment target specified in the podspec were honored.

I just wish that a contributor of CocoaPods would 1. acknowledge that this is an accurate description of an actual issue, 2. clearly marks the issue as unsolvable for [reasons], or 3. clearly marks the issue as solvable with [technique].

A (maybe naive) technique would be to have pod lib lint and pod trunk push use as the deployment target the aggregate (maximum) of the deployment targets specified by the podspec and its dependencies. So it libA specifies iOS 11.0+ and depends on libB that specifies iOS 12.0+, we'd use 12.0 as the IPHONEOS_DEPLOYMENT_TARGET when linting libA. Of course, things become much more complicated as we start to consider subspecs, plus technical challenges I don't foresee because I'm far from being a build expert. And this is exactly why this issue exists: as a call for contributions from CocoaPods contributors towards a solution.

At some point in the future, Xcode 14.2 will no longer be usable. What will we do then, if we can't pod lib lint and pod trunk push? 🤷

[paulb777]

To be pedantic, this is really an issue with the dependency podspecs, not with CocoaPods itself. The podspecs are specifying they should be built for an iOS version that is not supported by the building Xcode.

From the numerous Podfiles that do post_install script updates to dependent pod IPHONEOS_DEPLOYMENT_TARGET settings, it seems to be the case that the only impact of building for a newer platform version than specified by the podspec is extra deprecation warnings. It would be nice to know definitively that there also isn't the risk of breakages beyond that.

I can't speak for other CocoaPods contributors, but I would be fine with a PR providing an option for pod lib lint and pod trunk push to specify higher platform minimum deployment versions.

In the meantime, I would encourage podspec providers to work with their dependencies to update their podspecs to be accurate for modern Xcode versions. Worse case workaround is forking the dependent podspec's and updating the versions.

[groue]

I can't speak for other CocoaPods contributors, but I would be fine with a PR providing an option for pod lib lint and pod trunk push to specify higher platform minimum deployment versions.

Yes, that's an idea that allows everybody to move on, without having to wait for dependencies to update their podspecs (a slow an uncertain process).

In real life, podspec authors, when they use this new feature, would specify the exact same versions as in their podspec, though. So maybe this extra configuration could be just replaced by using the values that are already provided in the podspec. This sounds much simpler, easier to understand than the current behavior, and just as effective as the extra configuration you suggest.

Let's also take care that asking dependencies to update their podspec has serious drawbacks. Not only this is slow and uncertain. But the library mentioned in the initial comment does not need to upgrade its dependencies. GRBD + SQLCipher 3.4.2+ is a perfectly valid combination (if only CocoaPods would stop failing pod lib lint and pod trunk push on Xcode 14.3 only). Forcing GRDB to depend on the latest version of SQLCipher (with the future "fixed" podspec), just to accommodate this CocoaPods issue, would be a very unwelcome breaking change for GRDB users.

[bnickel]

@bnickel, I don't understand your question. Everything is said in the issue description.

Sorry, @groue, my comment was directed to @paulb777's quote and I should have tagged him. The comment suggested a lot of potential negative consequences for increasing the deployment version from what the dependency asked for and I'm just unclear on what that would be beyond an uptick in deprecation warnings.

To throw in a couple thoughts about the solution, I do feel like just patching lint will be enough. There are tools like Expo where React Native projects are built on the server without the developer ever seeing a Podfile. At some point, they're going to update their Xcode servers and builds are going to break. It also makes it incumbent on every Podspec distributor to either A) reach out to the their dependencies to update their repos or B) inform their users of hacks they need to inject in their Podfiles that do what we're suggesting here. Even if I never release another version of my project, my users are going to start seeing failures when they try building.

[shawnkc]

I'm having the same issue, even though I set my pod's spec to:
s.ios.deployment_target = '13.0'

When inspecting the generated linting project after using pod lib lint --no-clean, the dependent pods have their own minimum deploy targets set to 8.0.

Maybe it would work if there was a way within the podspec to define a deployment_target per sub-pod. I tried this for my project but it didn't work:

  s.ios.deployment_target = '13.0'
  s.dependency 'jetfire', '~>0.1.5'

  s.subspec 'jetfire' do |sub|
    sub.ios.deployment_target = '13.0'
  end

[dnglokpor]

I can't speak for other CocoaPods contributors, but I would be fine with a PR providing an option for pod lib lint and pod trunk push to specify higher platform minimum deployment versions.

Yes, that's an idea that allows everybody to move on, without having to wait for dependencies to update their podspecs (a slow an uncertain process).

In real life, podspec authors, when they use this new feature, would specify the exact same versions as in their podspec, though. So maybe this extra configuration could be just replaced by using the values that are already provided in the podspec. This sounds much simpler, easier to understand than the current behavior, and just as effective as the extra configuration you suggest.

Let's also take care that asking dependencies to update their podspec has serious drawbacks. Not only this is slow and uncertain. But the library mentioned in the initial comment does not need to upgrade its dependencies. GRBD + SQLCipher 3.4.2+ is a perfectly valid combination (if only CocoaPods would stop failing pod lib lint and pod trunk push on Xcode 14.3 only). Forcing GRDB to depend on the latest version of SQLCipher (with the future "fixed" podspec), just to accommodate this CocoaPods issue, would be a very unwelcome breaking change for GRDB users.

I am facing this issue as well. The workarounds work fine on the app side with the pod install but pod lib lint is a blocker for our CI pipeline. Was there any progress made towards a solution like suggested by here ?

[groue]

I'm not sure I understand what is the suggested course of action so that this issue is fixed. Xcode 15.1 will soon ship and we're still stuck on Xcode 14.2 to run pod trunk push.

[agruchala]

Man, You push podspec into your own spec repo, you ca run pod trunk push with sources of external sped repos W dniu niedz., 15.10.2023 o 09:34 Gwendal Roué ***@***.***> napisał(a):

…

I'm not sure I understand what is the suggested course of action so that this issue is fixed. Xcode 15.1 will soon ship and we're still stuck on Xcode 14.2 to run pod trunk push. — Reply to this email directly, view it on GitHub <#11839 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLQNXK2TVQHVXGFRZ7RF5TX7OGXTAVCNFSM6AAAAAAWPXICKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGMYDMNJRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[agruchala]

Contact me on twitter.

[stidch]

This issue looks related to #12033

[stidch]

In the hope of receiving some feedback in this thread. i am now posting my question from #12033 (comment) also here.

I am particularly interested in the question of whether this is actually an Xcode or Cocoapods problem.

---

Are there any updates? We can still not use Xcode 15 because we can't release our project, because pod lib lint fails with the

SDK does not contain 'libarclite' at the path ...

error.

1. pod install ☑️
   Consuming dependencies with a lower deployment target than `12.0 is not a problem, since we can workaround the issue by setting

   config.build_settings['IPHONEOS_DEPLOYMENT_TARGET']

in our Podfile (see #12033 (comment)).

2. pod lib lint ❌
   But for the same (the "libarclite") issue when running pod lib lint we don't have a solution yet.

In that case the Xcode Sample Project all the Pods have their original Deployment Target which might be lower than 12.0 and therefor the build resp. the pod lib lint command fails with the SDK does not contain 'libarclite' at the path ... error.

Forking Cocoapods and use a custom version with a "hotfix" as described in #12033 (comment) is not an option for me.

Questions:

• Is this actually an Xcode or a Cocoapods issue?
• If it's a Cocoapods issue: are there any plans for a fix?
• Does anyone knows another workaround than the mentioned above?

Any help is very much appreciated!

[groue]

@orta Today, trying to pod trunk push the new GRDB version with Xcode 14.2, in order to avoid this issue, I got the following error:

% xcode-select -p
/Applications/Xcode.app/Contents/Developer

% xcodebuild -version
Xcode 14.2
Build version 14C18

% pod --version
1.14.3

% pod trunk push --allow-warnings
[!] Found podspec `GRDB.swift.podspec`
Updating spec repo `trunk`
Validating podspec
 -> GRDB.swift (6.24.2)
    - ERROR | [iOS] unknown: Encountered an unknown error (unexpected token at 'objc[78819]: Class XROS1_0SimRuntime is implemented in both /Library/Developer/CoreSimulator/Volumes/xrOS_21N5259j/Library/Developer/CoreSimulator/Profiles/Runtimes/xrOS 1.0.simruntime/Contents/MacOS/xrOS 1.0 (0x102cf40e0) and /Library/Developer/CoreSimulator/Volumes/xrOS_21N305/Library/Developer/CoreSimulator/Profiles/Runtimes/xrOS 1.0.simruntime/Contents/MacOS/xrOS 1.0 (0x102d080e0). One of the two will be used. Which one is undefined.
') during validation.

[!] The spec did not pass validation, due to 1 error.

I don't know the source of the error, but the presence of xrOS (aka visionOS) in the error message makes me think that the mere presence of Xcode 15.2 on the drive is enough to have Xcode 14.2 fail.

This issue has turned into a total blocker.

Today, GRDB 6.24.2 is the first version that is only available with SPM, and not available with CocoaPods. CocoaPods users are no longer able to upgrade their copy of GRDB. This is concerning, but users have a workaround: they can switch to SPM (more or less easily). What's the real bummer is that GRDB+SQLCipher is only available through CocoaPods, due to the incompatibility of SPM with SQLCipher. I have no solution to suggest to GRDB+SQLCipher users as long as this issue exists.

---

EDIT: GRDB+SQLCipher users can visit this discussion for more information: groue/GRDB.swift#1495

[paulb777]

To work around the xrOS issue, open /Library/Developer/CoreSimulator/Volumes in the Finder, and delete any extra copies of xrOS simulators. You'll need to repeat after restarting the Mac.

[groue]

I just upgraded to Sonoma, which has invalidated my copy of Xcode 14.2. Thank you for all those years of services, Cocoapods! Time for a farewell 🙏❤️