›

Compilation i386

Eddy58Eddy58 Membre
08:03 modifié dans Xcode et Developer Tools #1
La procédure à  suivre pour compiler en universal binary où en simple exécutable i386 est [url=http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_compiling/chapter_2_section_3.html#//apple_ref/doc/uid/TP40002217-//apple_ref/doc/uid/TP40002217-CH206-159440-TPXREF141<br />]ici[/url]. J'ai essayé sur un de mes projets pur Objective-Cocoa et à  part quelques warnings à  corriger (bénins je pense) n'apparaissant pas lors d'une build PPC, l'application est correctement générée, mais rien encore pour la tester :P, mais normalement ça devrait fonctionner sans accrocs. :)

Réponses

  • aranaudaranaud Membre
    08:03 modifié #2
    C'est bizarre, j'ai du mal à  croire que çà  a marché.
    Du doit avoir deux exécutables ?

    Tes warning, il ne ressemblerait pas à  ça :
    /usr/bin/ld: warning /System/Library/Frameworks/Cocoa.framework/Cocoa cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)

    http://www.objective-cocoa.org/forum/index.php?topic=951.30

    Peut-tu mettre un exemple ?
  • Eddy58Eddy58 Membre
    juin 2005 modifié #3
    Les 3 possibilitées fonctionnent : Build PPC seule (of course ;)), build Intel seule, et universal binary (PPC+Intel).
    En faites, en plus de cocher les deux cases (dans le cas d'un universal binary), il faut également choisir un autre SDK (Universal) comme sur le grab joint à  ce post. Ca se configure en ouvrant les infos du projet dans Groups&Files. Normalement, c'est réglé sur "Current MacOS". Si l'option "Mac OS X 10.4 (Universal)" n'est pas disponible, il faut l'installer en faisant une installlation personnalisée du package XCode 2.1, et en allant cocher la bonne option dans la rubrique "Cross-Development".
    Avant de compiler, il faut aussi se mettre en mode "Deployment".
    Et puis une fois ceci fait normalement pas de problème, mis à  part quelques warnings mineurs. :)

    [Fichier joint supprimé par l'administrateur]
  • aranaudaranaud Membre
    08:03 modifié #4
    L'option "Mac OS X 10.4 (Universal)" n'est pas disponible même après avoir installer "universal binary". Est qu'un redémarrage est nécessaire ?

    Juste pour information, qu'elle qui se passe si tu compiles un projet avec de l'Altivec.
  • Eddy58Eddy58 Membre
    08:03 modifié #5
    dans 1118562747:

    L'option "Mac OS X 10.4 (Universal)" n'est pas disponible même après avoir installer "universal binary". Est qu'un redémarrage est nécessaire ?

    Non normalement c'est disponible de suite, c'est curieux que tu ne l'ai pas. ???

    dans 1118562747:

    Juste pour information, qu'elle qui se passe si tu compiles un projet avec de l'Altivec.

    Je n'en sais rien, pour ça il faut voir la doc universal_binary, voir ce qu'ils disent... :o
  • VeillardVeillard Membre
    08:03 modifié #6
    Il me semble que l'Altivec ne soit pas reconnu par l'i386.  :-\\
  • ChachaChacha Membre
    08:03 modifié #7
    Juste pour ajouter mon témoignage : moi aussi j'ai essayé de compiler en UniversalBinary, PPC+Intel, et ça marche merveilleusement bien. Tous les fichiers sont compilés deux fois, et il y a deux phases de link. Mais un seul exécutable !

    dans 1120203635:

    Il me semble que l'Altivec ne soit pas reconnu par l'i386.  :-\\


    Il faut passer par les libraries de haut niveau (Accelerate.framework) pour être peinard, mais pour ceux qui savaient programmer directement en Altivec... ben ça devient moins intéressant tout-à -coup.

    Sinon, vous trouvez que c'est utile, ou pédant, de faire des applis compilées pour Intel dès maintenant ?

    +
    Chacha
  • muqaddarmuqaddar Administrateur
    08:03 modifié #8
    Pour savoir si ça marche bien, il faudrait pouvoir lancer ton prog sur un mactel ! ;-)
  • VeillardVeillard Membre
    08:03 modifié #9
    Pour ma part, j'ai pas le choix, je suis toujours sous Panther...  :'(
  • Eddy58Eddy58 Membre
    juillet 2005 modifié #10
    dans 1120205368:

    Sinon, vous trouvez que c'est utile, ou pédant, de faire des applis compilées pour Intel dès maintenant ?

    Ben je trouve ça inutile pour le moment, vu que personne n'a encore de MacIntel, à  part quelques développeurs. Disons que la compilation Intel permet de procéder à  un certain débuggage si des warnings ou des erreurs qui n'apparaissent pas lors de la compilation PPC surviennent. De plus, tant que je n'aurais pas un MacIntel sous la main, je ne mettrais pas la version Intel de mes applis à  disposition tant que toutes les fonctions n'auront pas été testées, même si la compilation se passe à  merveille, peut-être qu'il y a des vices cachés dans certains cas. Peut-être aussi qu'il n'y en a pas, mais ça me dérange de mettre à  disposition une appli dont on est pas à  100% sûr de son bon fonctionnement..:)
  • ChachaChacha Membre
    08:03 modifié #11
    dans 1120216464:

    Disons que la compilation Intel permet de procéder à  un certain débuggage si des warnings ou des erreurs qui n'apparaissent pas lors de la compilation PPC surviennent.
    (...)
    ça me dérange de mettre à  disposition une appli dont on n'est pas à  100% sûr

    On est d'accords; mais en même temps, la version Intel que l'on peut produire a beau être potentiellement plus bugguée, personne ne le saura puisque personne n'a de MacTel pour le moment... sauf quelques développeurs, qui sont, eux, sujets à  faire des bugs reports ! Donc il me paraà®t plus intéressant de compiler quand même pour Intel, quitte à  mettre dans la doc "expérimental" et indiquer que les bugs reports sont les bienvenus. Au pire, ça marche pas; au mieux, ça marche et tout le monde est content. Et dans tous les cas, ça permet de faire une veille technologique sur la compilation pour Intel : peut-être va-t-on soulever des problèmes intéresants, découvrir des incompatibilités cachées, contribuer à  améliorer, en fait !

    +
    Chacha
  • Eddy58Eddy58 Membre
    08:03 modifié #12
    dans 1120218835:

    Donc il me paraà®t plus intéressant de compiler quand même pour Intel, quitte à  mettre dans la doc "expérimental" et indiquer que les bugs reports sont les bienvenus. Au pire, ça marche pas; au mieux, ça marche et tout le monde est content. Et dans tous les cas, ça permet de faire une veille technologique sur la compilation pour Intel : peut-être va-t-on soulever des problèmes intéresants, découvrir des incompatibilités cachées, contribuer à  améliorer, en fait !

    Ok, c'est une solution, mais aux risques et périls de l'utilisateur si le soft manipule des données sensibles de celui-ci. Tout dépend de la nature du soft en faites je dirais, si les données sont sensibles, l'utilisateur prendra-t-il le risque d'utiliser une version expérimentale ?
    Si les données traitées ne sont pas d'une "grande" importance, alors là  oui je pense qu'on peut se permettre de fournir une version intel non testée... Mais d'un autre côté c'est vrai que pour des données sensibles, l'utilisateur peut faire des tests avec des données factices (au détriment de sa productivité il est vrai), et si tout va bien passer en utilisation réelle apres... :o
  • ChachaChacha Membre
    08:03 modifié #13
    dans 1120227293:

    l'utilisateur prendra-t-il le risque d'utiliser une version expérimentale ?

    J'ai envie de dire "on l'avait prévenu", même si c'est très hypocrite puisque personne ne lit les docs.

    En fait, il y a une question que je me pose : si on a un MacIntel, et un programme PPC+Intel. Peut-on exécuter la partie PPC à  travers Rosetta, ou est-ce impossible ? Si ce n'est pas possible, on risque d'avoir une dérive "tout Intel" après la grande transition de 2007, même si en théorie il suffirait de décocher la case "Intel" à  la compilation pour être sûr de lancer Rosetta... mais ça c'est quand on a le code source, pas quand on est simple testeur !
  • Eddy58Eddy58 Membre
    08:03 modifié #14
    En toute logique, Rosetta exécute seulement les softs PPC only. Quand à  la dérive tout Intel, tu parles de la compilation des applis ? Vu le parc de machines PPC et la durée de vie de celles-ci, l'universal binary va être utilisé pendant de nombreuse années. :)
  • ChachaChacha Membre
    08:03 modifié #15
    dans 1120230575:

    En toute logique, Rosetta exécute seulement les softs PPC only. Quand à  la dérive tout Intel, tu parles de la compilation des applis ? Vu le parc de machines PPC et la durée de vie de celles-ci, l'universal binary va être utilisé pendant de nombreuse années. :)


    Oui mais considère le scénario suivant : je suis un jeune développeur; je m'achète un MacIntel. Je crée une appli Universal Binary. Je me rends compte que je ne peux pas tester la partie PPC, puisque c'est automatiquement le code Intel qui est lancé. Donc je décoche la case "PPC", puisque je ne peux pas garantir que le code soit bon. Donc l'appli devient Intel only.
    Un vieux développeur vient me voir, il me dit "si tu voulais tester le PPC, tu n'aurais qu'à  décocher la case Intel, comme ça tu forcerais Rosetta à  se lancer". Ah, ouais, j'aurais pu faire ça. Pfou, pas envie. Trop long de tester deux fois les programmes.

    Alors, scénario catastrophe ou pas ?
  • Eddy58Eddy58 Membre
    juillet 2005 modifié #16
    dans 1120231812:

    Un vieux développeur vient me voir,

    Qui ça ?? ClicCool ?? ;D

    dans 1120231812:

    il me dit "si tu voulais tester le PPC, tu n'aurais qu'à  décocher la case Intel, comme ça tu forcerais Rosetta à  se lancer". Ah, ouais, j'aurais pu faire ça. Pfou, pas envie. Trop long de tester deux fois les programmes.

    Alors, scénario catastrophe ou pas ?

    Alors là , je dis que ça sera en la bonne conscience de chacun. Soit on est rigoureux et on fait tout ce qu'il faut pour assurer la fiabilité de l'appli et son support ppc et x86, soit on est pas rigoureux, on se fiche de l'utilisateur d'une certaine façon, et alors là  autant changer de boulot ou de hobby, selon l'individu.... :P
  • ChachaChacha Membre
    08:03 modifié #17
    dans 1120232504:

    dans 1120231812:

    Un vieux développeur vient me voir,

    Qui ça ?? ClicCool ?? ;D

    Bon anniversaire, au passage ;)



    Alors là , je dis que ça sera en la bonne conscience de chacun.


    Ouais. Allez, en tant que développeur rigoureux qui aimerait bien tester ses applis sur X86, mais qui ne peut pas car il n'en a pas, je te paye un coup  :p

    +
    Chacha
  • Eddy58Eddy58 Membre
    08:03 modifié #18
    Bien frais mon pastis Chacha, avec un gros glaçon. :)
    A la tienne, et aussi à  la santé des cocoaculteurs ! :p
  • muqaddarmuqaddar Administrateur
    08:03 modifié #19
    Ils vont p-e sortir un mac à  deux processeurs, un intel et un PPC pour les développeurs... lol.
  • ChachaChacha Membre
    juillet 2005 modifié #20
    dans 1120245001:

    Ils vont p-e sortir un mac à  deux processeurs, un intel et un PPC pour les développeurs... lol.

    Excellent ! Le premier ordinateur bipro à  architecture hybride; même Solaris ne doit pas savoir gérer ça !
  • Eddy58Eddy58 Membre
    08:03 modifié #21
    Et non ça existe déjà , ça a été fait sur Amiga. ;)
    Petit aperçu :
    Les cartes accélératrices de migration 68k->PPC comportent un 68k pour la bonne exécution de l'OS (AmigaOS 3.x pour 68k), et le PPC pour les applications qui en tirent partis. Mon 1200 est par exemple équipé d'une carte Blizzard comportant un 68040/25MHz et un PPC603e à  166MHz, carte datant de 1997/98 si mes souvenirs sont bons. Les cartes haut de gamme pour Amiga 4000 étaient équipées de 68060 à  50MHz et de PPC604e à  240MHz. Même si l'OS 3.9 est en 68k, des applis tirent partis de la carte accélératrice grâce à  un "mini-OS" permettant de programmer le PPC et la carte graphique BVision à  base de Permedia 2. De bons jeux de l'époque ont d'ailleurs été adaptés (Heretic 2, Shogo, Quake 1 et 2, Freespace et d'autres). L'AmigaOS 4 full PPC est en développement pour ces cartes, mais fonctionne en pre-release sur des Amigas NG d'architecture moderne. Enfin bon, l'histoire est compliquée de ce côté là ...
    Désolé pour le Off-Topic.:P
  • muqaddarmuqaddar Administrateur
    08:03 modifié #22
    Nostalgie qd tu nous tiens !
  • Eddy58Eddy58 Membre
    08:03 modifié #23
    Hé oui c'était une autre époque. :) D'ailleurs j'ai pas pu m'empêcher d'installer E-UAE (émulateur) sur mon Mac, et je suis en train de me retrouver tout les hits de l'époque afin de me faire ma collection. :o
  • Eddy58Eddy58 Membre
    08:03 modifié #24
    dans 1120245001:

    Ils vont p-e sortir un mac à  deux processeurs, un intel et un PPC pour les développeurs... lol.

    En faites, je me demande pourquoi un Rosetta dans le sens d'émulation x86->PPC n'existe pas ? Cela rendrait bien service aux développeurs. Techniquement, ce n'est pas impossible, si on peut le faire dans un sens on peut aussi le faire dans l'autre. Peut-être Apple y-a-t-il pensé, mais y a renoncé par peur de voir cette émulateur faire obstacle à  sa stratégie de migration, en effet, des utilisateurs verraient sûrement en cet émulateur un moyen de repousser leur achat. :o
  • fouffouf Membre
    08:03 modifié #25
    dans 1120860775:

    En faites, je me demande pourquoi un Rosetta dans le sens d'émulation x86->PPC n'existe pas ? Cela rendrait bien service aux développeurs. Techniquement, ce n'est pas impossible, si on peut le faire dans un sens on peut aussi le faire dans l'autre. Peut-être Apple y-a-t-il pensé, mais y a renoncé par peur de voir cette émulateur faire obstacle à  sa stratégie de migration, en effet, des utilisateurs verraient sûrement en cet émulateur un moyen de repousser leur achat. :o
    dans 1120860775:

    dans 1120245001:

    Ils vont p-e sortir un mac à  deux processeurs, un intel et un PPC pour les développeurs... lol.

    En faites, je me demande pourquoi un Rosetta dans le sens d'émulation x86->PPC n'existe pas ? Cela rendrait bien service aux développeurs. Techniquement, ce n'est pas impossible, si on peut le faire dans un sens on peut aussi le faire dans l'autre. Peut-être Apple y-a-t-il pensé, mais y a renoncé par peur de voir cette émulateur faire obstacle à  sa stratégie de migration, en effet, des utilisateurs verraient sûrement en cet émulateur un moyen de repousser leur achat. :o


    Il ya aussi une autre explication possible : Microsoft risque de vouloir empecher ca. En effet, ca permettrait de faire tourner Windaube sur Mac avec un emulateur beaucoup plus puissant que VitualPC. Faut voir.
  • Eddy58Eddy58 Membre
    août 2005 modifié #26
    Apple a mis en ligne une page pointant sur de nombreuses infos pour la compilation intel et l'universal binary. :o
  • AliGatorAliGator Membre, Modérateur
    08:03 modifié #27
    Rappelez vous du passage de 68k à  PPC, avec les applis FAT...
    Ca a duré un p'tet bout de temps, cette histoire d'applis FAT, qui est en somme l'équivalent des UB ;)
    Pourtant y'avait pas beaucoup de deveux à  avoir un 68k + un PPC pour tester leur appli... Mais ça a quand même bien marché.

    Et rappelez vous aussi le passage de OS9 à  OSX.
    Encore aujourd'hui (je viens même de vérifier) si on a une appli Carbon (j'ai testé avec photoshop 7, qui est en Bundle mais avec un dossier "MacOS" et un dossier "MacOSClassic"), si on fait Pomme-I sur l'application, on a une case que l'on peut cocher "Ouvrir dans l'environnement Classic"

    Pourquoi il n'y aurait pas la même chose pour ouvrir une appli UB dans Rosetta donc en mode PPC, au lieu de l'executer en natif avec le processeur Intel du Mactel ? (ou même en mode x86 sur un mac PPC si Rosetta existe un jour dans l'autre sens)...?
  • Eddy58Eddy58 Membre
    08:03 modifié #28
    dans 1125497809:

    Pourquoi il n'y aurait pas la même chose pour ouvrir une appli UB dans Rosetta donc en mode PPC, au lieu de l'executer en natif avec le processeur Intel du Mactel ?

    Cela ne devrait pas poser de problème, l'UB, ce n'est ni plus ni moins que deux binaires chacun dans leur fichier dans le bundle du soft. :)

    dans 1125497809:

    (ou même en mode x86 sur un mac PPC si Rosetta existe un jour dans l'autre sens)...?

    Je me pose la même question 4 posts au-dessus justement. ;)
Connectez-vous ou Inscrivez-vous pour répondre.