Après la mise à jour vers Xcode 7.3, l'erreur Cannot create __weak reference in file using manual reference counting
dans les fichiers pod. Quelqu'un a-t-il résolu ce problème?
Réponses:
Réglez Build Settings -> Apple LLVM 7.1 - Language - Objective C -> Weak References in Manual Retain Release
sur YES
.
Tiré des forums des développeurs Apple - Xcode 7.3b4, non-arc, ne peut pas créer de référence __weak .
Voici la réponse officielle d'Apple à partir du lien:
Ce problème se comporte comme prévu sur la base de ce qui suit: Nous sommes en train d'implémenter des références faibles dans tous les modes de langage Objective-C. Puisque «__weak» a historiquement été ignoré dans les modes de langage non-ARC (et non-GC), nous avons ajouté cette erreur pour signaler les endroits où la sémantique changera à l'avenir. Veuillez mettre à jour votre rapport de bogue pour nous indiquer si le problème persiste.
Donc, fondamentalement, si vous utilisez Pod pour des bibliothèques tierces, vous devez soit supprimer __weak dans non-ARC, soit attendre la mise à jour.
Mettre à jour le 23/03
J'aurais dû faire plus de recherches sur les drapeaux que je peux transmettre à complier afin de contourner ce genre de choses. Mais fondamentalement, vous ne devriez pas utiliser __weak
en mode non-ARC à partir de maintenant pour éviter tout conflit inattendu. Pour les utilisateurs de cocoapods, vous n'avez pas besoin de supprimer __weak
ou d'attendre la mise à jour, mais définissez l' Weak References in Manual Retain Release
indicateur dans les paramètres de construction sur OUI, comme l'a dit Lean. J'espère que cette aide.
La meilleure façon de résoudre ce problème est d'ajouter un post_install
script à votre fichier Podfile qui définit l' Weak References in Manual Retain Release
indicateur sur yes
toutes vos cibles de pod. Pour ce faire, collez simplement le code suivant au bas de votre fichier Podfile
.
post_install do |installer_representation|
installer_representation.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['CLANG_ENABLE_OBJC_WEAK'] ||= 'YES'
end
end
end
Parfois, cela entraîne une erreur -fobjc-weak is not supported on the current deployment target
. Vous pouvez résoudre ce problème en ajoutant une autre option de configuration, forçant tous les pods à cibler la version souhaitée (en fonction de cette réponse ):
post_install do |installer_representation|
installer_representation.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['CLANG_ENABLE_OBJC_WEAK'] ||= 'YES'
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.3'
end
end
end
Solution de contournement pour les références faibles de Facebook dans FBSettings.m
Pour Podfile, il est possible d'écrire un script à exécuter après l'installation / la mise à jour du pod, décrit ce qui suit.
post_install do | installer |
classy_pods_target = installer.pods_project.targets.find {| target | target.name == 'Facebook-iOS-SDK'}
classy_pods_target.build_configurations.each do | config |
config.build_settings['CLANG_ENABLE_OBJC_WEAK'] ||= 'YES'
end
end
CLANG_ENABLE_OBJC_WEAK comment trouver les mots de la magie ça. .
J'ai trouvé ça.
Je suppose que cela signifie supprimer __weak
https://forums.developer.apple.com/thread/38934
Euh, y at-il jamais eu une telle chose comme une référence de variable faible sous MRR [manual retention-release]? «__weak» signifie une ou les deux choses suivantes:
Une référence sans propriétaire (c'est-à-dire ne représentant pas un compte de rétention)
Une référence de remise à zéro (c'est-à-dire que le runtime est remis à zéro lorsque l'objet référencé est désalloué).
# 1 ne s'applique pas à MRR, car vous ne conservez tout simplement pas la variable de toute façon.
# 2 ne s'applique pas non plus à MRR, car le support d'exécution est dans GC et ARC [comptage automatique de références], que vous n'utilisez pas.
Il semble que le compilateur se plaint maintenant de ne pas pouvoir faire ce qu'il ne pourrait jamais faire. (Et dans le cas d'un délégué d'application, vous ne pourriez pas faire la différence au moment de l'exécution, car le délégué d'application n'est généralement jamais désalloué.)
Ou changez __weak
en __unsafeunretained
. Cela résoudra le problème de la tradition. Depuis MRC (avant xCode 4 -) __weak n'était pas dans iOS.
-Wall -Wextra -Wno-unused-parameter
indicateurs d'avertissement activés.