Xcode 14.3 fix: Pass the -f option when resolving the path to the symlinked source.

[chrisvasselli]

🌈

Fixes the issue where archives fail when using Xcode 14.3. #11808

Xcode 14.3 is now using a relative path in its symlink for frameworks. Without the -f flag, this relative path would be evaluated relative to the working directory of the script being executed, instead of relative to the framework symlink itself. With the -f flag, it resolves that relative path and returns the full path to the source.

bundle exec rake spec failed, but it looks like maybe just because there were changes? Snapshot testing maybe? Also, it might make sense to add a test case to handle this scenario, but I don't know CocoaPods well enough to know what to add or where.

rake.txt

[ehagerty]

Chip: Apple M1 Max
Memory: 64 GB
macOS: 13.4 Beta (22F5027f)

Hi, forgive me if this is the wrong way to suggest it, but in embed_frameworks_script.rb I needed to change your use of readlink to the alternative greadlink which is installed via Brew with coreutils and which by default isn't aliased in place of readlink. Also, when building for macos, the script Pods-Runner-frameworks.sh also needs to use greadlink but it required me to use the full path to the binary whereas in embed_frameworks_script.rb it only required the binary name. By using the fully qualified binary in embed_frameworks_script.rb, it then generates that into Pods-Runner-frameworks.sh so I assume that is the only place that needs a change (if I am right at all in the first place).

[gali8]

+1

[holyavkin]

consider renaming the PR and adding a prefix:
Xcode 14.3 fix:

[chrisvasselli]

Chip: Apple M1 Max Memory: 64 GB macOS: 13.4 Beta (22F5027f)

Hi, forgive me if this is the wrong way to suggest it, but in embed_frameworks_script.rb I needed to change your use of readlink to the alternative greadlink which is installed via Brew with coreutils and which by default isn't aliased in place of readlink. Also, when building for macos, the script Pods-Runner-frameworks.sh also needs to use greadlink but it required me to use the full path to the binary whereas in embed_frameworks_script.rb it only required the binary name. By using the fully qualified binary in embed_frameworks_script.rb, it then generates that into Pods-Runner-frameworks.sh so I assume that is the only place that needs a change (if I am right at all in the first place).

Thanks for the suggestion! What did greadlink do that readlink -f didn't?

[chrisvasselli]

Hey @dnkoutso sorry to bug you, but this seems like a pretty urgent fix now that Xcode 14.3 is out, and you seem like the author of a bunch of recent commits. Are you able to take a look at this PR, or suggest someone I could reach out to?

[ehagerty]

Chip: Apple M1 Max Memory: 64 GB macOS: 13.4 Beta (22F5027f)
Hi, forgive me if this is the wrong way to suggest it, but in embed_frameworks_script.rb I needed to change your use of readlink to the alternative greadlink which is installed via Brew with coreutils and which by default isn't aliased in place of readlink. Also, when building for macos, the script Pods-Runner-frameworks.sh also needs to use greadlink but it required me to use the full path to the binary whereas in embed_frameworks_script.rb it only required the binary name. By using the fully qualified binary in embed_frameworks_script.rb, it then generates that into Pods-Runner-frameworks.sh so I assume that is the only place that needs a change (if I am right at all in the first place).

Thanks for the suggestion! What did greadlink do that readlink -f didn't?

Hi @chrisvasselli i should first thank you for all your work to find this in the first place! using readlink gives an error saying it doesn't know what to do with the -f option, although humorously it then says you could try the -f option... I recalled reading somewhere about the old school readlink command being not quite the same as the greadlink command on the mac so tried it and it ran to completion. I apologise if I've got the wrong end of the stick in making this suggestion, but did want to help others get past the error - as you did.

[chamodanethra]

This solution is working. I used this workaround for a Flutter project running on 3.7.7.
Thanks, @chrisvasselli

[olmosbek]

good job bro. Thanks!

[Danny-SS]

This looks great. We have been dead in getting our pipeline fixed with Xcode 14.3. I hope this PR gets merged soon!

[nickjun00]

Hi, I cant fix it with my Flutter project. Could you help me please?

[jaybhum]

Hey nickjun03,

Hi, I cant fix it with my Flutter project. Could you help me please?

I managed to solve the issue by doing the following:

1. Download the cocoapods repository and extract it in a folder
2. make the change in embed_frameworks_script.rb as shown above
3. Follow the steps for 'Set up a local dev copy of CocoaPods' here : https://guides.cocoapods.org/using/unreleased-features . The real world walk through is very helpful. I did not have to perform 'git checkout swift' by the way. If you are missing bundle, you can install it by: sudo gem install bundler:2.3.26
4. In your Flutter's ios folder, you can perform pod deintegrate , delete podfile.lock,
5. I had to ensure that the iOS development version needs to be at least 9.0. So I edit the last block of Podfile to be:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)
  end
  installer.generated_projects.each do |project|
        project.targets.each do |target|
            target.build_configurations.each do |config|
              if config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'].to_f < 9.0
                config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '11.0'
              end
             end
        end
 end
end

6. Then do pod install but with the local installation, like this example: /Users/orta/spiel/ruby/CocoaPods/bin/pod install
7. Then, perform Archive (DO NOT Run in Flutter before that! That will re-do pod install with the system's Pod and negate Step 6.)

I hope this helps!

[chamodanethra]

Flutter 3.7.10 has fixed this: flutter/flutter#123890

[appsowner]

upgrade Flutter 3.7.10 solution for my

[rafaellop]

Doesn't work in some cases:
flutter/flutter#124081 (comment)

[zwiya]

this works after spending days Thanks !!!! for flutter edit find file called
Pods-Runner-frameworks.sh
and then search for this

source="$(readlink "${source}")"

and add the -f

Enjoy <3

[ibatuhanozdemir]

Thank you soo much. Works like a charm.

[fivegreenapples]

@chrisvasselli I appreciate your work on this. Saved me a ton of time. Thanks

[dnkoutso]

Running CI might need integration specs update.

[chrisvasselli]

@dnkoutso thanks for taking a look. Created a PR for the specs update, and added an entry to the changelog.

CocoaPods/cocoapods-integration-specs#341

[chrisvasselli]

@ehagerty the correct option to pass is -f not -r, did you try that?

[geminiwen]

meet the same issue on Xcode 14.3 with flutter

[maccman]

Just ran into this!

[concernedrat]

Ran into this with Xcode 14.3 and Flutter today

[arnab]

I’m pretty sure anyone running XCode 14.3 would run into this problem.

I suggest just subscribing to this issue instead of commenting on it (unless you have more insights into the problem).

Then the emails/notifications from this issue (which go to all subscribers) will be more useful (and about actual progress/fix).

[dnkoutso]

@chrisvasselli I merged the integration specs PR can you update the submodule here and then push? It should go green.

[samueldeschamps]

Ran into the same issue on Xcode 14.3 with Flutter...
The bad luck was somehow Xcode just updated to 14.3 in my Mac without asking me, breaking with all my Flutter projects.

[chrisvasselli]

@dnkoutso done.

[serbixote]

can we merge this already?

[knottx]

same issue on Xcode 14.3 with flutter

[dnkoutso]

I would love to ship this but unfortunately I keep seeing various reports like this one and this one that perhaps its not the best fix?

I havent had time to look myself into the actual issue. I might end up shipping 1.12.1 by EOW unless any other maintainer does it before me.

[chrisvasselli]

@dnkoutso Makes sense to be cautious! My sense though is that fixing this issue will unblock far more people than it will negatively impact.

And for what it's worth, neither of those reports you linked worry me, and I believe both should be resolved by the fix. I think what you're actually seeing is people having trouble applying the workaround.

I think part of what's going on is that the fix is in a script that generates a bunch of files. And the workaround I also gave was to just manually find/replace the line in question in the files that the script generated. So I think some people are trying the workaround, and then maybe not finding all the files, or reporting the name of the generated file that they needed to modify.

If there's one issue that I do think is worth keeping an eye on, it's probably this one. This person had a non-standard version of the readlink binary on his machine that didn't support the flag I added. For them, my fix will not work. However, it won't make things worse for them either.

Their suggested solution is to use greadlink, but since that would be adding a new dependency to cocoapods, I'm not sure how easy/desirable that would be. In the meantime though, I don't think it should prevent pushing out this change.

[ehagerty]

Hey @chrisvasselli, thanks for the link to my suggestion :-) I feel famous now!

@dnkoutso I feel comfortable that you can and should move ahead with the 'readlink' fix as is.

NB, it isn't that I have a non standard version of readlink. I'm fairly sure that /anyone/ who tries to use the /default/ version of readlink on an M1 mac will likely hit the -f error. I've seen this bug in places as disparate as builds of mongodb, fish shell etc. The reason people may /not/ hit the error is because the standard install of coreutils via brew creates a symbolic link from 'readlink' to the 'greadlink' binary. In other words, I'm hitting the error because I /am/ using the standard binary and everyone else is letting their system 'magically' use the 'non-standard' greadlink.

The other tickets are as @chrisvasselli suggests - a ton of noise because people crashed ahead with find and replace / HEAD branches etc instead of reading enough to understand what was going on. Anyone who us using brew/coreutils is covered - it is probably only antique C developers like me that have a system configured without the extra 'magic'.

I'm not a doctor, but I do play one on television - ymmv.

[fivegreenapples]

Hi @ehagerty re. your readlink/greadlink comments, I have done a little digging and I haven't found what you're suggesting. In fact rather the opposite:

On a friend's Mac Studio, M1 Max, macOS 13.3.1 (22E261), with no coreutils installed by brew, his readlink binary is very happy with readlink -f. Also the same on my wife's M1 Macbook Air (admittedly running macOS 12.something). fwiw on my Intel based iMac, also with no coreutils, my readlink is also fine.

So I kinda wonder what readlink is on your mac? Can you run which readlink to see where it is and confirm it is in the standard location, and also confirm it isn't symlinked to something unexpected. Also man readlink to see what that shows, and lastly double check that readlink -f errors.

Sorry that is a bunch of things to look at but I'd like to get to the bottom of it if possible.

For reference, this is output from my friend's M1 Mac:

~$ which readlink
/usr/bin/readlink
~$ ls -l /usr/bin/ | grep readlink
-rwxr-xr-x   2 root   wheel    135008  1 Apr 17:46 readlink

~$ man readlink
STAT(1)                     General Commands Manual                    STAT(1)

NAME
     stat, readlink – display file status

SYNOPSIS
     stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]
     readlink [-fn] [file ...]
etc...

[chrisvasselli]

@fivegreenapples @ehagerty As far as I can tell I also don't have coreutils or greadlink installed:

brew list | grep coreutils
# no output

which readlink
/usr/bin/readlink

which greadlink
greadlink not found

And /usr/bin/readlink is not aliased.

I'm on an M1 MacBookPro running macOS 13.2.1.

[HoustonDuane]

Hi folks, I see that 1.12.1 has been released, and I've tried that with

sudo gem install cocoapods
sudo xcode-select -s /Applications/Xcode14_3.app/Contents/Developer
pod install

I make sure the Podfile.lock has updated the cocoapods version:

After hitting Clean Build Folder and rerunning the app, the problem persists.

Any idea?

[fivegreenapples]

@HoustonDuane I'm pretty sure your issue is the same as this one: #11808 (comment)

(To be clear I mean the thing mentioned in that comment, not the github issue it is part of)

[HoustonDuane]

@fivegreenapples Did you mean that upgrading to 1.12.1 does not solve the libarclite problem? Unfortunately I can't easily move up the deployment target to 11.0. Can anybody help?

[fivegreenapples]

@HoustonDuane

Did you mean that upgrading to 1.12.1 does not solve the libarclite problem?

No - 1.12.1 fixes only the 3 issues mentioned here: https://github.com/CocoaPods/CocoaPods/releases/tag/1.12.1
One of those is the fix in this pull request but that is not related to libarclite

Unfortunately I can't easily move up the deployment target to 11.0. Can anybody help?

From what I understand you just need to be above 8.0 (per this comment further down in that thread: #11808 (comment))

hth

[HoustonDuane]

@fivegreenapples A million thanks for your reply, I managed to solve the issue by adding the following to my Podfile:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        # Fix libarclite_xxx.a file not found.
        target.build_configurations.each do |config|
            config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
        end
    end
end

To anyone who's wondering, you only need to specify the deployment target greater than 8.0. I've not tried 8.0 itself, but 9.0 solves my problem (and I exactly need it to be 9.0).

Whew, it's been a journey! I've noticed Xcode 14.3 is blazing fast compared to 14.1, don't know what magic the developers from Apple has done.

Now I don't need to write redundant self. in closures in many cases! That's probably the biggest reason why I upgrade to Xcode 14.3. The new backDeployed attribute also interests me, but I don't know how big the scope would be of the features Apple fellas decide to back deploy to older iOS versions (from iOS 13.0 maybe?).

[magsimillion]

hello! first of all thank you so much for your fix; adding the -f flag has helped in fixing ONE problem. the thing is, another has arisen and I have the vague suspicion that it has something to do with the new Xcode update:

In signing & capabilities I continuously get these two errors:

• Failed to register bundle identifier
  The app identifier "{our identifier}" cannot be registered to your development team because it is not available. Change your bundle identifier to a unique string to try again.
• No profiles for '{our identifier}' were found
  Xcode couldn't find any iOS App Development provisioning profiles matching '{our identifier}'.

wouldn't these two errors imply that we a) already have an identifier with the same name but also b) it can't find the identifier?
now I've tried every fix I could find with a simple google search, but it still doesn't work. these fixes that I found were pretty old though and I've wondered, if this could be due to Xcode having similar path finding issues as described above in order to find our profile?

just as an aside: we have registered this identifier over on developer.apple.com and have successfully uploaded and released our app multiple times (only for beta testing now), but this has now stopped working since the update came out (and forced us to update in order to continue releasing the app).

cheers!

[usmanabid94]

For the people facing error in Xcode after update to 14.3.

In your xcode, Go to PODS folder :
Target Support Files => Pods-{Your Project} => Pods-{Your Project}-frameworks

Change

source="$(readlink "${source}")"
this :

source="$(readlink -f "${source}")"

[imilakovic]

There's no need for workarounds any more, just upgrade CocoaPods to version 1.12.1

Please see this tag for more details:
https://github.com/CocoaPods/CocoaPods/releases/tag/1.12.1

[Ccalary]

The same question，in Xcode15，I did this，solved it。Targets -> Build Setting -> Build Options -> User Script Sandboxing，set Yes To No。You can search "ENABLE_USER_SCRIPT_SANDBOXING"