web-dev-qa-db-fra.com

Xcode 10 ne pouvant pas archiver le projet

J'essaie de télécharger une nouvelle version d'une application qui est déjà dans l'AppStore. La version précédente a été téléchargée à l'aide de Xcode 9.4. Mais maintenant, Xcode 10 sera nécessaire pour obtenir l’approbation.

Malheureusement, Xcode ne peut pas archiver le projet , je suis donc bloqué sur la première étape, sans même pouvoir générer le fichier binaire pour la soumission.

Il n'y a pas d'erreur: selon Xcode, notre processus d'archivage compte plus de 2000 tâches et reste bloqué dans des tâches arbitraires (toujours les mêmes). Xcode ne plante pas, ne montre pas d'erreur et ne se plaint pas. Il ne peut tout simplement pas réussir cette tâche et le IDE y reste pour toujours.

Nous l'avons essayé sur différentes machines et avons également essayé deux versions: la version précédente de l'application (pouvant être archivée avec Xcode 9.4) et une nouvelle version, migrée avec succès vers Swift 4.2.

METTRE À JOUR:

  • Le système de construction existant ne fonctionne pas non plus.
  • Construit pour un Périphérique iOS générique également bloqué (pas seulement l’archivage), mais le logiciel est compilé et fonctionne sur le simulateur.
  • J'ai essayé de compiler la version non migrée en sélectionnant Swift 4 (au lieu de 4.2) et les mêmes résultats.
  • Joué avec des niveaux d'optimisation, une compilation complète ou incrémentale, etc., et toujours les mêmes résultats.
  • Dans Xcode 9.4, il construit pour Périphérique iOS générique bien sans rien changer.
iosxcodexcode10swift4.2
7
nbloqs

Enfin, j'ai supprimé "armv7" de "Architectures valides" des paramètres de construction du projet. C'est archivé! Cela signifie que l'iPhone 4S n'est plus compatible ..__ Mais, je ne pense pas qu'Apple va déprécier 4S de cette façon. En plongeant dans les journaux, j’ai trouvé qu’il était difficile de créer des symboles dSYM.

[17:15:49]: ▸ Generating 'ZUS_INHOUSE_DEV.app.dSYM'
[17:16:15]: ▸
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _lum_convert
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _ff_init_desc_hscale
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _lum_h_scale
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _ff_init_desc_cfmt_convert
[17:16:15]: ▸
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _ff_init_desc_chscale
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _chr_h_scale
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _ff_init_desc_no_chr
[17:16:15]: ▸ (arm64)  could not find object file symbol for symbol _no_chr_scale
[17:16:30]: ▸ (arm64)  could not find object file symbol for symbol _vlc_entry__audio_filter_libscaletempo_pitch
[17:16:30]: ▸
[17:16:30]: ▸
[17:16:30]: ▸
[17:16:30]: ▸
[17:16:30]: ▸
[17:16:30]: ▸
[17:16:30]: ▸ (arm64)  failed to insert symbol '_best_overlap_offset_float' in the debug map.

Ainsi, je suppose, une autre solution de contournement est de changer le "Format d'informations de débogage" de "DWARF avec fichier dSYM" en "DWARF".

9
LexTang

Comme LexTang l'a laissé entendre, l'une des solutions de contournement qui fonctionne, sans qu'il soit nécessaire de supprimer armv7 des architectures valides, consiste à définir "DWARF" pour "Format d'information de débogage". Malheureusement, nous perdons ainsi l’option de la symbolisation automatique des collisions. De cette façon, trouver la cause d’un accident est beaucoup plus difficile, mais pas impossible. Sur les liens suivants, vous trouverez plus d’informations sur les accidents symboliques sur iOS: https://coderwall.com/p/ezdcmg/symbolicating-an-ios-crash-log-without-the-original-dsym-filehttps://www.apteligent.com/technical-resource/symbolicating-an-ios-crash-report

0
Sergio