À la Croisée des Chemins: crossroad, environnement de cross-compilation

• # Licence Windows 7

  Posté par Xaapyks le 18 octobre 2013 à 15:59. Évalué à 3.

  

  Or j'ai une licence Windows 7 inutilisée depuis l'achat de mon ordinateur portable, et le contrat d'utilisation m'autorise à le lancer dans une machine virtuelle

  En es-tu sûr ?
  J'ai voulu le faire aussi avec une licence W7 OEM d'un PC portable sur lequel je n'avais jamais booté le Windows et donc jamais activé moi-même. (J'avais tout reformaté au tout premier allumage)
  Et en récupérant une ISO Win 7 (légalement d'ailleurs il me semble… car provenant des serveurs publics Microsoft, mais apparemment c'est flou, même s'ils proposent l'ISO on lit parfois que c'est interdit ?!) j'ai voulu la réutiliser… Sauf que ça ne s'est jamais activé dans la VM.

  Et même si tu arrivais à l'activer, je doute que ça soit toléré par la licence OEM.
  Bon à moins que la licence que tu as eu avec ton PC ne soit pas OEM…

  • [^] # Re: Licence Windows 7

    Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 17:01. Évalué à 3.

    

    Salut,

    J'ai essayé de retrouver vite fait la licence Win 7 sur le site Microsoft après ton message, mais je tombe que sur Windows 8 partout. Je vais dormir là, mais je chercherai demain à nouveau, sauf si quelqu'un trouve avant et poste le lien ici. :-)

    En tous cas, j'avais lu la licence de mon OS exact à l'époque, spécifiquement pour savoir cela, et ce point précis était très clairement marqué dedans (vraiment non-ambigu d'après moi, ou alors de manière très fourbe). Je me souviens qu'il y avait un point précis dans le contrat qui dit qu'on peut l'utiliser dans une VM.

    En plus comme j'avais pas de CD Windows (comment souvent maintenant dans les portables, qui te vendent avec une sorte de partition cachée qui permet de réinstaller l'OS), j'ai même demandé au vendeur du portable de me le filer, en disant au support que c'était pour l'utiliser en VM, plutôt qu'en OS principal, car autorisé par le contrat. Et ils m'ont filé un iso officiel sans même poser plus de questions.

    Donc oui j'en suis sûr, autant que faire se peut quand on n'est pas juriste. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Licence Windows 7

      Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 18:29. Évalué à 7.

      

      Bon j'ai fait une petite recherche avant d'aller au lit, parce que ça me faisait chier de reporter au lendemain.

      J'arrive pas à retrouver le contrat (je pense qu'il est peut-être quelque part dans mon ordi), et tous les liens sur le net que je trouve et qui menaient à un lien Windows 7 sont morts et redirigent vers des pages génériques Windows 8 (bravo Microsoft pour les liens pérennes!).
      Par contre j'ai trouvé cette page de answer.microsoft.com qui cite ce qui semble être exactement le paragraphe que j'avais en tête, et pour exactement mon OS (Windows 7 Home Premium OEM): http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_install/am-i-allow-to-install-the-oem-version-of-windows-7/7bcab9e6-f886-4af9-b96f-35a2e5840642

      d. Use with Virtualization Technologies. Instead of using the software directly on the licensed
      computer, you may install and use the software within only one virtual (or otherwise emulated)
      hardware system on the licensed computer. When used in a virtualized environment, content
      protected by digital rights management technology, BitLocker or any full volume disk drive
      encryption technology may not be as secure as protected content not in a virtualized
      environment. You should comply with all domestic and international laws that apply to such
      protected content.

      Donc oui on a bien le droit (bien sûr ça s'applique parce que je n'utilise pas mon Win sur la plateforme matérielle, où j'ai un Linux).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Licence Windows 7

        Posté par Xaapyks le 21 octobre 2013 à 09:51. Évalué à 2.

        

        on the licensed computer

        Ah oui c'est là que j'ai péché alors… Merci pour le paragraphe précis.

        Mais ça n'empêche que je me demande toujours comment techniquement l'activation fait pour fonctionner alors que la licence est déjà liée sur un autre matériel. Peut-être une liste blanche si il détecte un environnement de VM ?

  • [^] # Re: Licence Windows 7

    Posté par NeoX le 19 octobre 2013 à 00:14. Évalué à 1.

    

    ca depend peut-etre de savoir si c'est une Licence OEM donc liée à la machine, au fabricant
    ou une licence normale (windows pro ?)

    • [^] # Re: Licence Windows 7

      Posté par Alex G. le 21 octobre 2013 à 09:32. Évalué à 1.

      

      Je pense surtout que les licences d'activations sont liées à des releases précises de windows, donc s'il a téléchargé une image ISO il n'est pas sur d'être tombé sur la release exact qui allait avec son PC et donc son code d'activation.

• # Comparatif

  Posté par Larry Cow le 18 octobre 2013 à 16:15. Évalué à 4.

  

  Comment ça se positionne par rapport aux solutions existantes (typiquement mxe.cc ) ?

  • [^] # Re: Comparatif

    Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 17:41. Évalué à 4.

    

    Je connaissais pas MXE. Mais je viens de jeter un œil.

    Déjà MXE maintient sa propre liste de paquetage de dépendances. D'une, ça doit être un travail de dingue de les garder à jour et vérifier que chacun compile proprement à chaque nouvelle version; de deux, je suis persuadé qu'il n'est pas à jour sur plein de paquetages à cause du premier point (sauf si l'équipe est vraiment grosse?); de trois, même si l'installation des dépendances reste simplifiée certes par rapport à tout faire à la main, il n'empêche que tu te tapes des dizaines de compilations pour un gros projet.

    Quand je compile GIMP par exemple, j'ai pas compté, mais avec les dépendances de dépendances, je pense qu'y a bien une vingtaine au moins de paquets installés. Ben ça se fait en genre une minute. C'est du pré-compilé. Donc c'est rapide, et surtout ça marche tout le temps. Le seul cas où une installation de dépendance foire avec crossroad, c'est si les serveurs Fedora sont down. :-)
    MXE, ils compilent tout sur l'ordi de build. Donc c'est lent, et ça peut foirer (car on sait tous que les compilations, c'est pas parce que ça marche bien chez le dév que ça marche chez vous (même si c'est normalement le but recherché). Y a beaucoup plus de paramètres en compte.
    Et surtout je ne me charge pas de cette liste de dépendances! Donc j'en ai genre probablement bien plus que MXE sans rien avoir à faire. Crossroad va simplement télécharger la liste des paquets Fedora dès que tu l'invoques et est donc toujours à jour par rapport à la dite liste.
    Voici donc la liste complète des dépendances de Crossroad: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_12.3/noarch/
    MXE a ça apparemment: https://github.com/mxe/mxe/tree/master/src
    C'est pas mal aussi, et j'ai pas compté précisément pour voir qui a la plus grosse. Mais je préfère de loin ne pas avoir à me préoccuper de cela.

    Pareil j'ai l'impression que MXE va jusqu'à lui-même compiler MinGW ou MinGW-w64. Franchement toutes les grosses distrib ont MinGW/MinGW-w64 d'installable pour ton OS. Et si vraiment tu veux une version plus récente, y a des builds nocturnes officiels aussi (en tous cas pour MinGW-w64). Vraiment pourquoi s'embêter à compiler ça?
    Tout comme les dépendances, je préfère de loin déléguer.

    Pour le reste, si tu regardes le tuto de MXE, ça aide pas beaucoup plus que cela. J'ai l'impression que son point principal, c'est de proposer des Makefile pour diverses dépendances.

    Mais ils te demandent toujours de modifier tes variables d'environnement et de taper les configure et cmake à rallonge. C'était justement la partie chiante que je suis content d'avoir automatisé. Après tout, c'est toujours les mêmes options. Pourquoi me faire chier à les taper ou copier-coller à chaque fois plutôt que les automatiser dans un script?

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• # À propos du nom

  Posté par nizan666 le 18 octobre 2013 à 16:23. Évalué à 3.

  

  La chanson raconterait comment Robert Johnson aurait rencontré le diable à un croisement de route.

  Le nom et sa référence au diable est très bien vue mais la chanson "Cross road blues" ne parle pas de ça et la légende de la rencontre du diable à la croisée des chemins si souvent attribuée à Robert Johnson est le fait d'un autre bluesman, Tommy Johnson, auteur (ou en tous cas interprète connu) de "Canned Heat Blues". Il y a par ailleurs une référence au diable chez Robert Johnson dans "Me and the devil" mais pour dire qu'il est traite sa femme diaboliquement mal, si j'ai bien compris.

  • [^] # Re: À propos du nom

    Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 18:01. Évalué à 3.

    

    La légende concerne les deux personnages. Comme tu le dis toi-même, Robert Johnson a une autre chanson où le diable est cité explicitement: "Me and the Devil Blues".
    Quant à "Cross Road Blues", même si le diable n'est pas explicitement nommé, toutes les interprétations convergent vers l'histoire de la rencontre avec le diable. Et les paroles sont tout de même assez perturbantes dans ce sens. Ça parle du fait qu'il est à la croisée des chemins et fait du stop, mais personne le prend en stop. Pendant ce temps, la nuit se met à tomber, et il a vraiment peur. À la fin il dit "I believe I'm sinking down", ce qu'on peut comprendre par le fait qu'il croit être perdu. Peut-être parce qu'il est trop tard pour lui, trop tard pour sauver son âme?

    Dans tous les cas, je vois pas pourquoi le fait qu'il y ait aussi des histoires sur Tommy Johnson, cela interdirait aussi celles sur Robert Johnson. A priori des historiens pensent que l'un comme l'autre aimaient à entretenir eux-même ces légendes. C'était un bon marketing déjà, en tant que bluesmen. Aussi ils étaient l'un comme l'autre assez connus pour être plutôt roublard. Certaines interprétations du caractère de Robert Johnson laissent penser qu'il pensait que ça le protégeait ainsi que les gens puissent penser qu'il ait un lien avec le diable. Car si on a peur de lui comme associé du diable, oserait-on s'en prendre à lui (probablement oui, car on pense que sa mort pourrait être dû à un mari jaloux, qui n'aurait donc pas eu suffisamment peur de la légende!)?

    Dans tous les cas, une chose est sûre: de nos jours, la légende du pacte avec le diable concerne ces deux personnages. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: À propos du nom

      Posté par ZeroHeure le 18 octobre 2013 à 20:21. Évalué à 2.

      

      La roublardise ne s'est pas perdue : dans le film "Crossroad, la route du blues" on croise plein de bluesman américains contemporains, prêts à raconter toutes sortes de légendes!

      Il y a aussi la BD de Frantz Duchazeau « Le rêve de Meteor Slim », où on peut rencontrer, outre Robert Johnson, des sacrés personnages du blues!

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: À propos du nom

        Posté par Alex G. le 21 octobre 2013 à 09:36. Évalué à 1.

        

        Et bien sur le film "Ô brother" des frères Coen où ils prennent le bluesman à la croisée des chemins juste après son pacte :-)

        • [^] # Re: À propos du nom

          Posté par dlewin le 21 octobre 2013 à 09:50. Évalué à 2.

          

          EEhh et le film sur Robert Johnson avec des morceaux (au sens figuré) de Ry Cooder et Stevie vaï dedans ?

          Crossroads

          Pour être amateur de Blues, et donc Robert Johnson, c'est bien de lui dont il s'agit : celui qui est revenu après une "certaine absence" et enregistrer ces morceaux dans un hôtel. Nombre de reportages montrent John Lee Hooker, BB King (qui étaient potes) etc, racontant (ou entretenant le mythe) sur ce fait.

          • [^] # Re: À propos du nom

            Posté par julo4lfr le 21 octobre 2013 à 14:46. Évalué à 1.

            

            Et dans le documentaire Le cimetière du diable

• # Question de noob

  Posté par ariasuni le 18 octobre 2013 à 16:30. Évalué à 3.

  

  Je n’ai jamais fait de cross-compilation, mais pourquoi doit-on faire crossroad --symlink w64 gimp?

  Écrit en Bépo selon l’orthographe de 1990

  • [^] # Re: Question de noob

    Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 17:16. Évalué à 2.

    

    Mon outil configure le projet pour s'installer dans un préfixe donné, ainsi que toutes les dépendances pré-compilées (car on veut pas mélanger des binaires Win avec son OS). Dans la pratique, ça rajoute simplement un --prefix automatique à ton ./configure pour qu'on ait pas à y penser à chaque fois.

    Ce crossroad --symlink est juste un petit raccourci de mon outil pour créer un lien (nommé gimp) qui lie l'environnement w64. J'utilise ça pour ma VM Virtualbox qui communique avec mon OS notamment par un dossier partagé. C'est plus simple que d'échanger un zip avec ma VM (ce serait un peu ridicule).

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Question de noob

      Posté par MrLapinot (site web personnel) le 19 octobre 2013 à 15:02. Évalué à 2.

      

      Question de noob qui commence à cross-compiler pour Windows : tu fais comment pour partager un dossier avec ta VM simplement ?

      • [^] # Re: Question de noob

        Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 15:39. Évalué à 3.

        

        Pour Virtualbox: dans les settings de ta VM, y a un onglet "Shared Folders". Tu cliques dessus, et tu décides d'un répertoire partagé (genre $HOME/shared ou quoi que ce soit qui soit pratique pour toi).

        Oublie pas de le mettre en auto-mount (à un moment, je comprenais pas pourquoi la VM d'une amie voyait pas son répertoire partagé. J'ai mis pas mal de temps jusqu'à ce que je remarque que c'était pas en auto-mount).

        Il faudra aussi que tu installes les Guest Additions dans ta VM (de toutes façons, t'as intérêt. Sans ça t'as plein de trucs qui marchent pas, et surtout t'auras une résolution qui correspond pas à ton écran, donc l'utilisation sera peu pratique). C'est super facile, VirtualBox a un item dans le menu de la VM, une fois démarrée, qui te permet de télécharger et installer les Guest Additions. Rien à faire d'autre que cliquer et attendre.

        Une fois cela fait, tu verras une nouvelle "partition" dans ton Windows au prochain boot, qui sera en vrai le contenu de ton répertoire partagé. Tu pourras donc échanger en direct et en un instant des fichiers de toute taille entre Nux et Win. Et tout lien symbolique dans ce répertoire apparaîtra comme un vrai fichier/répertoire dans Win. C'est juste super pratique.

        Pour autre chose que Virtualbox, aucune idée.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Question de noob

          Posté par MrLapinot (site web personnel) le 19 octobre 2013 à 16:18. Évalué à 2.

          

          Magique. Merci beaucoup.

• # Intéressant

  Posté par freem le 18 octobre 2013 à 16:40. Évalué à 2.

  

  J'ai toujours voulu tester la cross compilation, mais ai toujours préféré maintenir un projet code::blocks portable et rebooter, plutôt que de devoir penser par moi-même…

  Et pile en ce moment je songeais à me remettre sur autorealm que j'ai juste complètement lâché depuis… pfff trop longtemps. Ton truc va me permettre de pouvoir enfin vérifier que ça marche réellement sous windows \o/ ( j'ai toujours gardé la portabilité à l'esprit, donc, en théorie il ne devrait y avoir aucun souci, mais… )

  Donc, merci.

  PS: et juste histoire d'avoir un truc négatif à dire, mon compilateur français bloque sur ce passage: " et prônes à l'erreur" et me suggère un remplacement par " et facilitant l'erreur", mais c'est vraiment juste pour faire chier :p

  • [^] # Re: Intéressant

    Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 03:07. Évalué à 3.

    

    Cool, tiens moi au courant si tu essaies crossroad. Tout retour d'utilisation est bienvenu.

    En tous les cas, pour les projets un peu gros, je pense qu'il vaut mieux régulièrement au moins compiler dans d'autres OS dès le début (même si on ne teste et que le port est pas pour l'immédiat. Ça ne coûte pas grand chose — avec un tel outil — au minimum de juste cross-compiler et voir que ça le fait sans erreur). À mon avis, même en faisant attention, le diable est dans les détails comme on dit. Mais bien sûr, les corrections seront bien plus simples et minimes si tu as essayé d'être portable dès le début. Et peut-être même qu'il n'en aura aucune, qui sait?!

    Merci pour la faute de voc. Il semblerait que tu aies raison. Ces dernières années, j'ai parlé plus souvent anglais ou japonais que français. Forcément ça joue des tours. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Intéressant

      Posté par freem le 22 octobre 2013 à 11:59. Évalué à 1. Dernière modification le 22 octobre 2013 à 12:02.

      

      Mais bien sûr, les corrections seront bien plus simples et minimes si tu as essayé d'être portable dès le début. Et peut-être même qu'il n'en aura aucune, qui sait?!

      Il y en aura au moins une, j'ai une ligne qui empêche spécifiquement que ça marche sur windows en guise de todo :D
      Cette fameuse ligne ( un throw dans un #ifdef WIN32 ) doit être remplacée par un mécanisme pour contrer le fait qu'il n'y a pas de /etc sous windows.
      Je pense que je vais finir par me faire une lib pour les emplacements de fichiers de config ( en utilisant un fichier passé en param en 1er, puis fallback sur config user, et finalement sur config système ), d'ailleurs, ça me prendra 30 lignes et m'évitera de le faire dès que je veux gérer des config de façon portable et en prenant en compte les spec XDG…

      Merci pour la faute de voc.

      Ce n'était que pour avoir un truc négatif sur ton 'nal, fallait que je trouve un truc… En plus c'est une histoire de syntaxe sur ce coup, pas de voc :p

      Sinon, pendant que j'y pense, si tu as une batterie de tests, je peux toujours voir ce que ça donne sur mes systèmes… Me connaissant, je ne serai pas surpris qu'il manque des dépendances dans ta description ( système lourdement allégé, si je suis puis dire )

      • [^] # Re: Intéressant

        Posté par Jehan (site web personnel, Mastodon) le 22 octobre 2013 à 12:51. Évalué à 2.

        

        Sinon, pendant que j'y pense, si tu as une batterie de tests, je peux toujours voir ce que ça donne sur mes systèmes… Me connaissant, je ne serai pas surpris qu'il manque des dépendances dans ta description ( système lourdement allégé, si je suis puis dire )

        Batterie de tests pour vérifier des trucs génériques sur des logiciels à cross-compiler ou pour crossroad même?

        Si c'est des tests génériques pour des logiciels, non je fournis pas ça avec crossroad. Il ne s'agit que d'un système de compilation, pas un environnement de test.

        Si tu parles de tests pour vérifier que crossroad marche, ben le plus simple, c'est de l'installer et l'essayer. J'ai vraiment tout fait pour que ce soit extrêmement facile à installer (avec pip3 notamment, sinon un simple ./setup.py très standard) et utiliser (commandes courtes, faciles à se remémorer, et similaire à une compilation pour le système natif). S'il te manque une dépendance que j'ai pas vue, donc pas citée, tu auras une erreur, et tu pourras me la remonter. :-)

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Intéressant

          Posté par freem le 22 octobre 2013 à 14:26. Évalué à 1.

          

          Si c'est des tests génériques pour des logiciels, non je fournis pas ça avec crossroad. Il ne s'agit que d'un système de compilation, pas un environnement de test.

          Ah non! Y'a assez d'outil qui font le café comme ça, merci :)

          S'il te manque une dépendance que j'ai pas vue, donc pas citée, tu auras une erreur, et tu pourras me la remonter. :-)

          C'est bien mon intention.

• # Par rapport à une compilation via Wine

  Posté par Julien Jorge (site web personnel) le 18 octobre 2013 à 16:58. Évalué à 4.

  

  J'ai pour habitude de compiler les versions Windows de mes jeux en utilisant Wine, après y avoir installé et compilé toutes les dépendances. C'est un peu galère sur plusieurs points, notamment parce que MinGW est super lent et galère à mettre à jour, que certaines bibliothèques mettent par défaut une éternité à compiler (Boost notamment) et que CMake ne trouve pas les bibliothèques tout seul sous Windows. Du coup j'évite de modifier le ~/.wine/drive_c et d'y mettre à jour les bibliothèques et outils.

  Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ? Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?

  • [^] # Re: Par rapport à une compilation via Wine

    Posté par Jehan (site web personnel, Mastodon) le 18 octobre 2013 à 17:11. Évalué à 3.

    

    Salut,

    J'ai jamais tenté de compiler sous nux avec Wine et MinGW. Mais sous Windows avec MinGW, c'est aussi d'une lenteur effroyable. Je sais pas ce que le compilo fait, mais il le fait pas vite. :-D

    Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ?

    Je pense oui. Avec la cross-compilation native (pas Wine ou autre environnement bâtard entre deux-OS pour l'exécution. C'est "natif" dans le sens où ça utilise un compilo fait pour tourner sous nux, seulement il compile à destination d'un autre OS), ça va super vite chez moi (tout aussi vite que la compilation nux pour nux).

    Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?

    Oui. Il suffit de le configurer, compiler et l'installer avant ton projet, pareil que le projet normal. Il sera installé dans le même préfixe que le reste (les libs installées par Fedora en particulier), et donc quand tu configureras ton projet, il trouvera ces dépendances compilées également.
    GIMP master par exemple nécessite babl et GEGL master aussi, qui ne sont pas présents dans Fedora aussi, ainsi qu'une version de cairo supérieure à ce que Fedora propose. J'installe donc ces 3 dépendances supplémentaires avant d'installer GIMP. Ça marche nickel.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• # Du côté de Gentoo…

  Posté par Fopossum le 18 octobre 2013 à 18:20. Évalué à 7. Dernière modification le 18 octobre 2013 à 18:21.

  

  Il existe une solution qui va bien pour ça, c'est crossdev.

  Son utilisation est détaillée dans le Gentoo Embedded Handbook. Il peut très bien être utilisé pour mettre en place une chaîne de cross-compilation complète, il supporte déjà de très nombreuses architectures et targets. Je l’ai utilisé pour rapido voir si j’arrivais à compiler mon promier hello-world aussi pour Windows. En un peu plus d’½h j'avais un environnement de cross-compil dispo et utilisable

  user $ crossdev -t help
  Supported Architectures:
     - alpha                                     - arm / armeb / aarch64
     - hppa (parisc)                             - ia64
     - i386 / i486 / i586 / i686 (x86)           - m68k
     - mips / mipsel / mips64 / mips64el
     - powerpc (ppc) / powerpc64 (ppc64)
     - sparc / sparc64                           - s390 / s390x
     - sh / sh[1-5] / sh64                       - x86_64 (amd64)
  Supported C Libraries:
     - glibc (gnu)
     - klibc       [prob wont work]
     - newlib      [bare metal/no operating system]
     - uclibc      [not all arches are ported]
  Special Targets:
     - avr      http://www.nongnu.org/avr-libc/
     - bfin     http://blackfin.uclinux.org/
     - h8300    http://h8300-hms.sourceforge.net/
     - mingw32  http://www.mingw.org/
     - msp430   http://mspgcc.sourceforge.net/
     - nios2    http://www.altera.com/products/ip/processors/nios2/ni2-index.html
     - xc16x    http://www.infineon.com/
     - ee / iop / dvp (ps2) [Playstation 2 targets]
     - ppu / spu (cell) [Cell/Playstation 3 targets]
  Softfloat toolchains:
     Include 'softfloat' in the 'vendor' field
     e.g. armeb-softfloat-linux-uclibc  powerpc-booya_softfloat-linux-gnu
  

  Y’a p’tet une ou deux idée à prendre de ce côté là pour étendre ton outil.

  Je pense aussi que chez Debian, vu le nombre d'archi qu'ils maintiennent, il doit aussi y avoir un outil de ce genre qui pourrait t'être utile.

  Quoi qu’il en soit, bravo pour ton boulot.

  cd /pub && more beer

  • [^] # Re: Du côté de Gentoo…

    Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 01:29. Évalué à 6.

    

    Ça a l'air cool. J'aime et ai toujours aimé Gentoo, c'est ma distribution préférée pour et la plus agréable à l'utilisation… hormis pour le temps qu'on y passe! C'est d'ailleurs la seule raison pour laquelle je ne l'utilise plus sur ma machine principale. Je veux plus passer des heures à compiler.

    Ceci dit, le problème majeur de crossdev, c'est que c'est encore un outil de distribution = pour cette distribution seulement. C'est cool pour les utilisateurs de la distrib, mais chiant pour les autres. crossroad se veut générique. Je l'ai commencé sur ma Mageia 3, puis le continue sur ma Linux Mint. Et je veux pouvoir cross-compiler aisément quelque soit ma prochaine distrib, si je venais à changer encore.
    Fedora (et Suse bien sûr par conséquent!) aussi ont des outils facilitant la cross-compilation, avec un wrapper de ./configure aussi, je crois (si je me souviens bien, j'avais regardé un tuto y a longtemps, mais n'ai jamais testé car j'ai pas de Fedora/Suse justement). C'est pareil. C'est du spécifique à une distrib, donc inintéressant pour moi.

    Apparemment crossdev est intégré à portage et permet donc de compiler l'ensemble de l'arbre de dépendances de Gentoo dans n'importe quel plateforme cible fournie par Gentoo. C'est vraiment cool. Ça permet définitivement plus de choses que crossroad puisque je fais que du Windows sur x86 32 et 64-bit pour le moment. Et ma liste de dépendances est limitée à ce que le projet Fedora veut bien pré-compiler, ce qui est forcément moins que l'ensemble des paquetages de Gentoo. Mais c'est bien le principe de Gentoo où on compile déjà tout de toutes façons. Ben là on peut compiler tout à nouveau, mais simplement pour une autre plateforme. :-)
    Mais bien sûr cela marche ainsi parce que c'est intimement lié à portage, donc à Gentoo. Et cela reste un système de cross-compilation que je ne pourrai pas essayer de sitôt.

    Et puis j'espère bien élargir bientôt le champs des possibilités de crossroad pour compiler vers d'autres plateformes!

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Du côté de Gentoo…

      Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 21 octobre 2013 à 08:11. Évalué à 4.

      

      « Ça a l'air cool. J'aime et ai toujours aimé Gentoo, c'est ma distribution préférée pour et la plus agréable à l'utilisation… hormis pour le temps qu'on y passe! C'est d'ailleurs la seule raison pour laquelle je ne l'utilise plus sur ma machine principale. Je veux plus passer des heures à compiler. »

      Il semble que ces dernières années ça se soit largement amélioré. Depuis quelques années on ne passe plus des plombes à gérer les mises à jour et leur lot de réglages manuels. Évidemment le compilateur trime toujours autant. Mais en temps humain, le progrès paraît fulgurant vu d'ici.

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

• # le troll du copyright

  Posté par chonyi le 18 octobre 2013 à 20:08. Évalué à 2.

  

  De ce que mes maigres connaissances sur le sujet me laissent entrevoir, le copyright est légiféré à l'international par la convention de Berne, qui prévoir aux articles 7 et 7bis que la durée de protection est de 50 ans après la mort de l'auteur ou 50 ans après la divulgation pour une œuvre collective.

  Ceci dit, cela voudrait dire que Mickey Mouse, protégé par le Mickey Mouse Protection Act aux US, n'est plus protégé ailleurs, M. Disney étant mort il y a plus de 50 ans… si quelqu'un peut apporter une contradiction, j'en serais très heureux !

  • [^] # Re: le troll du copyright

    Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 01:14. Évalué à 2.

    

    Moi j'ai toujours entendu dire que ça dépendait du pays. D'ailleurs les sites web qui diffusent du domaine public ont en général toujours un avertissement disant que le domaine public est connu pour un pays X (en général le pays du projet), et vous demandant de vérifier les lois du copyright dans votre pays — si différent — pour être sûr de pas enfreindre la loi.

    Ceci dit, je viens de regarder Copyright sur Wikipedia. Ça dit ça:

    En vertu de la Convention de Berne, la durée typique de la protection du droit d'auteur est de 50 ans pour la date de publication6. Il s'agit d'un défaut - les lois nationales sont généralement supérieures à cette durée.

    Donc tu as raison pour dire qu'il y a un accord international (sur 166 pays apparemment), mais comme toujours avec les lois internationales, les lois nationales prévalent. Or les pays légifèrent souvent des durées plus longues (jamais plus courtes, semblerait-il!).

    Ceci dit, cela voudrait dire que Mickey Mouse, protégé par le Mickey Mouse Protection Act aux US, n'est plus protégé ailleurs, M. Disney étant mort il y a plus de 50 ans… si quelqu'un peut apporter une contradiction, j'en serais très heureux !

    Ben moi j'en suis vraiment pas heureux, mais la loi que tu citais est justement la contradiction. Tu l'avais donc apportée toi-même! D'ailleurs c'est pour cela que les gens l'appellent du sobriquet "Mickey Mouse Protection Act", puisqu'elle est le résultat des coups de pouce de Disney vers le gouvernement pour justement que Mickey ne passe pas dans le domaine public.

    En gros si je comprends bien cet acte d'extension déjà prolonge les droits d'auteur à 70 ans par défaut. Puis fait un cas spécial pour les œuvres d'entreprise (comme Mickey!) qui passent soit à 95 ans après publication ou 120 ans après création (le plus long est choisi!). Donc malheureusement Mickey est loin d'être dans le domaine public, du moins pas pour ceux qui habitent aux US.
    Pour en savoir plus, va lire l'article que tu pointes sur Wikipedia. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: le troll du copyright

      Posté par chonyi le 19 octobre 2013 à 09:56. Évalué à 2.

      

      Ben moi j'en suis vraiment pas heureux, mais la loi que tu citais est justement la contradiction. Tu l'avais donc apportée toi-même!

      C'est plus subtil que ça, je vais contredire ma propre contradiction, en une phrase : ce n'est pas parceque quelquechose est interdit aux US qu'il l'est en France…

      Contrairement à l'image qu'on a inconsciemment, il n'y a pas de loi planétaire ! Et donc ce n'est pas parcequ'aux US il est interdit de reproduire le dessin animé Mickey Mouse de 1936 qu'en France c'est interdit aussi… Autant les noms de marques peuvent être déposés dans plusieurs pays et avoir des durées renouvelées, autant le copyright ne se déclare pas en tant que tel, et donc est uniquement régi par la convention de Berne… Donc Mickey Mouse n'est pas protégé en France et si j'avais l'original du dessin animé Mickey Mouse de 1936, je serais parfaitement dans mon droit si je le reproduisais et le diffusais. J'aurai les droits d'auteur sur la réédition et pourrais même le diffuser sous licence CC0 (ce qui est le plus proche du domaine public en France, pays où on ne peut pas renoncer à ses droits d'auteur).

      Est-ce que quelqu'un peut contredire ça aussi ?

• # Petit test

  Posté par rewind (Mastodon) le 19 octobre 2013 à 11:12. Évalué à 3.

  

  J'ai testé un peu et j'ai trouvé ce que je pense être un bug. Le répertoire .cache/crossroad/prefix n'est pas créé et à un moment, ça pose problème, ça finit en exception.

  Sinon, pour le reste, j'ai installé ming-w64 sur ma Debian (unstable) et j'ai pu compilé quelques trucs, sans souci. J'ai installé des paquets depuis les dépôts Fedora, sans problème. Mais à un moment, il y a qqch qui a dû mal se passer et je n'arrive plus à compiler, je me retrouve avec une erreur :

  /usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/lib/crt2.o:
  dans la fonction « __tmainCRTStartup »:
  
  
  /tmp/buildd/mingw-w64-3.0.0/build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/../../mingw-w64-crt/crt/crtexe.c:285:
  référence indéfinie vers « _set_invalid_parameter_handler »
  

  Et même les trucs que j'avais réussi à compiler, ça ne marche plus. Je ne comprends rien. Si quelqu'un a eu le même genre de blague, ça m'intéresserait de comprendre.

  • [^] # Re: Petit test

    Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 11:55. Évalué à 4.

    

    Salut,

    J'ai testé un peu et j'ai trouvé ce que je pense être un bug. Le répertoire .cache/crossroad/prefix n'est pas créé et à un moment, ça pose problème, ça finit en exception.

    Bien trouvé. C'est pourquoi on devrait toujours réinitialiser son environnement de travail (cache, fichiers de config, etc.) pour tester convenablement un nouvel outil! :p Comme j'avais ce rép depuis longtemps, j'ai dû introduire un bug et ai oublié de tout détruire pour avoir un environnement vierge, comme un nouvel utilisateur. Merci pour le rapport. Corrigé et poussé maintenant. Je ferai une release mineure bientôt.

    /usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/lib/crt2.o:
    dans la fonction « __tmainCRTStartup »:

    /tmp/buildd/mingw-w64-3.0.0/build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/../../mingw-w64-crt/crt/crtexe.c:285:
    référence indéfinie vers « set_invalid_parameterhandler »

    Oui j'ai eu exactement la même. C'est un bug de mingw. Simplement des fonctions a priori oubliées dans les libs. Donc ça compile, mais ça foire au link.
    T'utilises quelle version de MinGW-w64? J'avais eu ce problème avec le dernier build nocturne automatique. J'ai même fait un bug report: https://sourceforge.net/p/mingw-w64/bugs/350/
    Tu peux voir exactement le même bug que toi dans le config.log que j'ai attaché au ticket.

    Comme j'avais aussi d'autres bugs de macros non définis dans des headers sur le MinGW-w64 stable plus vieux fourni par ma distro, j'utilise actuellement une sorte de mix immonde. J'utilise le build nocturne dans lequel j'ai remplacé les binaires libmingw32.a, libmingwex.a et crt2.o depuis le vieux build stable de ma distro (2.22.90.20120919-0ubuntu1+2).
    Ça marche nickel. Je conseille donc de faire ainsi en attendant le fix.
    N'hésite pas à reporter que t'as eu la même erreur dans le bug report. :-) Peut-être que cela poussera le bug dans les priorités si on est plusieurs à le rapporter.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Petit test

      Posté par rewind (Mastodon) le 19 octobre 2013 à 12:42. Évalué à 2.

      

      T'utilises quelle version de MinGW-w64?

      La 3.0.0 donc plutôt récente.

    • [^] # Re: Petit test

      Posté par rewind (Mastodon) le 19 octobre 2013 à 12:55. Évalué à 2.

      

      Est-ce que ce ne serait pas lié à ce bug aussi ?

      • [^] # Re: Petit test

        Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 13:07. Évalué à 2.

        

        Peut-être. Ça y ressemble en tous cas. Tu peux essayer de modifier les headers dont parle le gars en rajoutant ce #if. Si ça règle le problème, c'est probablement le même.

        J'avais vu ce rapport de bug en effet, mais j'en avais créé un autre car j'avais aussi d'autres erreurs (comme je dis dans mon rapport) et je dois pas toucher que la lib crt mais une autre aussi. Mais peut-être que les autres erreurs étaient seulement des conséquences du premier et que si on rajoute ce #if, ça corrige toutes les erreurs?

        Je ne sais pas. J'ai pas regardé dans le code. :-)

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Petit test

          Posté par rewind (Mastodon) le 19 octobre 2013 à 13:14. Évalué à 2.

          

          J'ai essayé mais en fait, ça ne résout rien, parce que ça vient de ce qui est déjà compilé par Mingw-w64, donc il faudrait tout recompiler Ming-w64 et vérifier que ça fonctionne. Parce que je pense que le bug est corrigé dans le trunk.

          • [^] # Re: Petit test

            Posté par rewind (Mastodon) le 19 octobre 2013 à 14:54. Évalué à 2.

            

            Du coup, j'ai essayé avec le build 20131004 mais j'ai le même bug. Je crois que je vais m'arrêter là pour l'instant et attendre que ce bug soit résolu.

            • [^] # Re: Petit test

              Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 15:00. Évalué à 3.

              

              Salut,

              Oui c'est justement le build avec lequel j'ai aussi eu le bug!
              Comme je le disais, pour moi ça a été réparé en copiant certains binaires d'une version plus vieille (2.22.90.20120919-0ubuntu1+2, celle fournie dans les dépôts de ma Mint).

              Mais si tu faisais juste ça pour tester, je peux comprendre que tu n'aies plus envie d'aller plus loin. Par contre si tu as un besoin réel de cross-compiler, mon contournement devrait fonctionner en attendant qu'ils corrigent upstream. :-)
              Dans tous les cas, merci pour avoir essayé et donné un retour!

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Petit test

                Posté par rewind (Mastodon) le 19 octobre 2013 à 15:20. Évalué à 4.

                

                Je vais avoir un besoin de cross-compiler pour le jeu que je développe et pour lequel j'aimerais bien fournir une version Windows à moyen terme. Je pensais que j'allais devoir me coltiner le montage d'un environnement de dev sous Windows et que ça allait être très galère. Donc, quand j'ai vu ton projet, j'ai crié hourra et j'ai essayé pour voir si c'était facile. Réponse : oui, c'est facile !

                Maintenant, comme je n'en ai pas besoin dans l'immédiat, je peux attendre la correction du bug. Si ça prend du temps cette correction, j'appliquerai ton astuce pour que ça marche. Mais en tout cas, je pense que je vais adopter ta solution de cross-compilation pour Windows. Elle m'a convaincue.

• # Bravo!

  Posté par devnewton 🍺 (site web personnel) le 19 octobre 2013 à 12:08. Évalué à 5.

  

  Enfin quelqu'un qui s'attaque à un problème majeur de C/C++!

  Je n'ai pas bien compris la partie gestion des dépendances: comment est-ce que l'on ajoute une lib perso?

  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • [^] # Re: Bravo!

    Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 12:58. Évalué à 5.

    

    Salut,

    Les dépendances pré-compilées sont fournies par le projet Fedora. Je me sers juste dans leur repo, décompresse et installe dans un répertoire que je crée et dont je me sers comme préfixe.
    Pour installer ta propre lib (perso, ou non disponible dans les dépendances pré-comp), tu la compiles et l'installes avec crossroad (crossroad configure && make && make install), tout simplement. Cela l'installera dans le même préfixe que tout le reste [*], mélangé avec les libs pré-compilées et ton projet final. Comme l'environnement est normalement bien configuré, le projet qui nécessite cette lib la verra lors de l'étape de configuration. En gros tu devrais retrouver exactement la même expérience que lorsque tu compiles ton projet et ses libs pour Linux.
    Le plus simple est d'essayer, et tu verras, ça vient naturellement pour qui compile régulièrement (ça n'apprend pas magiquement la logique de compilation à ceux qui comprennent pas ce qui se passe quand ils font un ./configure, make et make install, bien sûr).

    À propos, c'est pas que C et C++ théoriquement. Ma distrib fournit aussi des paquets nommés gnat-mingw-w64-x86-64, mingw-ocaml, gobjc++-mingw-w64-x86-64, et gfortran-mingw-w64-x86-64. J'en déduis qu'on devrait être capable de cross-compiler aussi en Ada, Objective C++, Objective Caml et Fortran. Et en fait j'ai déjà ajouté le code nécessaire dans crossroad. Donc si tu installes les dépendances adéquates, tu devrais pouvoir compiler une tripotée de projets différents.
    Cela étant dit, je dis "théoriquement", car je n'ai compilé que des projets C et C++ moi-même avec crossroad. Je n'ai jamais testé les autres langages en cross-comp, donc j'ai peut-être (probablement même!) loupé des trucs pour que ça marche (des variables d'environnement déjà très probablement, etc.).
    Néanmoins j'invite à tester quiconque en a besoin et je me ferai un plaisir de corriger crossroad quand je recevrai des rapports de bug pour d'autres langages (si possible avec des infos sur ce qui manque si vous le savez déjà).

    [*] crossroad ne fait pas du multi-préfixe car le but n'est nullement de reproduire un arbre complexe de préfixes dans ton Windows. Ça fait un unique préfixe et tout est dedans.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Bravo!

      Posté par rewind (Mastodon) le 19 octobre 2013 à 13:08. Évalué à 3.

      

      Je confirme que c'est assez naturel. Par exemple, pour SFML qui n'est pas dans le dépôt, j'ai décompressé les sources de SFML-2.1, j'ai installé les dépendances nécessaires à SFML :

      crossroad install freetype-devel
      crossroad install glew-devel
      crossroad install libjpeg-devel
      crossroad install openal-soft
      crossroad install libsndfile-devel
      

      Et ensuite, j'ai essayé de compiler. Bon, j'ai eu le bug cité ci-dessus mais je suis sûr que sinon, ça marche !

      • [^] # Re: Bravo!

        Posté par Jehan (site web personnel, Mastodon) le 19 octobre 2013 à 13:18. Évalué à 3.

        

        Oui ça a marché pour toi. C'est sûr, puisque ce bug que tu cites n'apparaît qu'au moment du link. Ça signifie que la compilation s'est passée jusqu'au bout et sans erreur. Seulement tu n'arrives pas à linker avec les libs de MinGW à cause de références manquantes, donc c'est la dernière étape pour faire le binaire final qui foire. C'est con.

        Mais tu devrais essayer un des contournement (soit le mien si tu peux trouver un MinGW stable d'avant 3.0, soit essayer de rajouter un #if dans le header comme l'autre rapport de bug propose, et voir si ça corrige aussi).

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• # Cross compilation

  Posté par diorcety le 19 octobre 2013 à 13:29. Évalué à 3.

  

  C'est exactement sur quoi je travail en ce moment, avec une autre personne.
  On travail sur le support par crosstool-ng des differents système.
  A terme (dans quelques mois) on pourra faire de la cross compilation depuis linux/darwin/windows pour linux/darwin/windows.

  Cependant crosstool-ng supporte déjà la target windows avec mingw64. Après moi j'utilise le système de recette de oe-lite pour construire mes dépendances.

• # Félicitations!

  Posté par ericfl le 19 octobre 2013 à 14:02. Évalué à 3.

  

  C'est toujours sympa de voir les projets d'infrastructure progresser alors que c'est pas simple de régler tous les détails ayant trait à ce genre de projet.
  L'ultime plan diabolique de Debian serait donc le port knt-amd64?

• # Ca marche avec Linux ??

  Posté par freejeff le 20 octobre 2013 à 12:17. Évalué à 1.

  

  Salut,

  je ne suis pas tres au point avec tout cela mais j'en aurais vraiment besoin.

  Nous avons fait un projet ou nous utilisons des libs bas niveau comme openmp,mpi,fftw3,…

  On les a toutes installees en dynamic sous nos machines, mais nous devons utiliser ce programme dans des endroits ou nous ne pouvons etre root, genre accelerateur de particules.

  Du coup si je pouvais avoir un bon gros executable ou alors un repertoire qui contient tout et que je peux lancer en local en gerant des variables d'environnement alors cela nous aideriait beaucoup. J'utilise ce Code en ce moment a l'Institut Paul Scherrer et j'ai vriament eu de la chance que les admins soient sympa.

  Donc si une telle chose est possible sous linux j'en serais ravi !

  Si tout ceci est trivial a faire n'hesitez pas a me le dire !

  • [^] # Re: Ca marche avec Linux ??

    Posté par Jehan (site web personnel, Mastodon) le 20 octobre 2013 à 13:45. Évalué à 5.

    

    Salut,

    Ca marche avec Linux ??

    Ben on est sur linuxfr.org, on parle de cross-compiler pour Windows depuis Linux. La toute première phrase de l'article est (emphase rajoutée) « Cross-compiler pour Windows sur une machine Linux est maintenant aussi simple que compiler pour Linux ». Ça parle de bash, zsh. Si tu cliques sur le lien pypi, ça dit que c'est pour "Operating System :: POSIX :: Linux", et si tu lis le README, je dis même que ça n'a été testé que sur une machine GNU/Linux. Donc la réponse est: oui, ça marche avec Linux. :-D

    Ou alors tu demandes si ça peut faire l'inverse: compiler pour Linux (comme OS cible) depuis une machine Windows? Et dans ce cas, la réponse est non, mais je me demande bien qui voudrait faire cela alors qu'on a quand même de supers outils natifs pour gérer des sources et compiler sous Linux!

    Ou alors tu demandes quelque chose d'autre, et là je pige pas. En fait je pige pas trop ton message.

    On les a toutes installees en dynamic sous nos machines, mais nous devons utiliser ce programme dans des endroits ou nous ne pouvons etre root, genre accelerateur de particules.

    Crossroad ne nécessite à aucun moment d'être root. Je dirais même plus: ne faites jamais de la cross-compilation en étant root! Je dirais même encore plus-plus (x 100): ne faites jamais — ô grand jamais — du développement en étant root, ni même du simple test de programme! Installez tout sur un préfixe local (mon préfixe usuel pour plein de choses est $HOME/.local par ex, voire un préfixe très temporaire, genre $HOME/test/ quand c'est vraiment juste un test que je veux pouvoir facilement défaire par un rm).

    Du coup si je pouvais avoir un bon gros executable ou alors un repertoire qui contient tout et que je peux lancer en local en gerant des variables d'environnement alors cela nous aideriait beaucoup. J'utilise ce Code en ce moment a l'Institut Paul Scherrer et j'ai vriament eu de la chance que les admins soient sympa.

    Comme dit plus haut, c'est vraiment pas dur d'installer des logiciels sans être root. Tu mets à jour le PATH de l'utilisateur qui va le lancer (dans bashrc, zshrc, ou autre équivalent selon ton shell, est un emplacement commun pour cela). Pour les libs partagés, tu peux modifier LD_LIBRARY_PATH par exemple (bien qu'il y ait plusieurs solutions, ça dépend de ce que tu veux faire exactement et comment. Jette un œil par exemple là: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
    Ensuite y a d'autres variables qui peuvent rentrer en jeu. Par exemple pour du Python, tu peux aussi modifier le PYTHONPATH, etc.

    Ceci dit, je comprends toujours pas le lien avec le journal qui parle de cross-compilation. :-p
    Tes machines cibles sont des Windows? (ça me ferait quand même vachement peur un accélérateur de particule contrôlé par un Windows!)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Ca marche avec Linux ??

      Posté par freejeff le 20 octobre 2013 à 19:07. Évalué à 1.

      

      Non en fait c'est beaucoup plus basique.

      On compile tout avec les libs system, dont openmp, mpi, fftw3, ….

      Compiler en static de Linux vers Linux demande de refaire tout le travail de makefile toute la compilation en local de toutes tes bibliotheques, si son systeme permettait de tout installer en local pour un packaging en local ca eviterait un boulot d'informaticien qui n'est pas vraiment le miens …

      Quand a ton lien sur les les bibliotheaues partagees, c'est justement le probleme … je ne sais pas ce que j'aurai lorsque j'arriverai. Par exemple la j'ai envoye deux semaines a l'avance ma demande d'installation de lib, mais non il n'avaient pas les RH pour le faire, ce que je peux comprendre. donc on arrive et tout a La Rache, on y arrive mais on perd du temps alors a 10k euros par journee c'est un peu la loose.

      je sais que j'aurais un linux 64 bits sans droits d'admin.

      Voila les contraintes …

      Apres c'est un pb de genie logiciel, je ne suis pas expert …

      • [^] # Re: Ca marche avec Linux ??

        Posté par Jehan (site web personnel, Mastodon) le 21 octobre 2013 à 05:57. Évalué à 3.

        

        Compiler en static de Linux vers Linux demande de refaire tout le travail de makefile toute la compilation en local de toutes tes bibliotheques

        Qu'appelles-tu "refaire tout le travail de makefile"? Entends-tu "modifier" le makefile? Parce que normalement tu ne devrais pas avoir à toucher aux Makefile. Il y a en général une option pour compiler la librairie en statique (--enable-static ou équivalent). Je ne compile jamais en statique, mais je sais que ça devrait être tout aussi simple qu'en dynamique.
        Ça te permettrait en effet d'avoir un gros binaire avec tout dedans et ça résoud le problème.

        Quand a ton lien sur les les bibliotheaues partagees, c'est justement le probleme … je ne sais pas ce que j'aurai lorsque j'arriverai.

        Comme dit plus haut, tu peux tout à fait installer tout dans un préfixe de ton choix. Donc "si", tu sais ce que tu auras quand tu arriveras. :-)
        Bien sûr, je ne conseillerais pas normalement ce type de procédure pour une belle install propre, avec des libs partagées par divers programmes, etc. Mais si cela te convient et peut te permettre de contourner l'administration trop procédurière, faire gagner des semaines de boulot à tout le monde, alors pourquoi pas.
        En gros tu crées ton préfixe perso. Par exemple $HOME/nomduprojet/ et tu compiles tous tes programmes avec --prefix=$HOME/nomduprojet/
        Tu voudras probablement temporairement changer ton $PATH, $ACLOCAL_FLAGS, $PKG_CONFIG_PATH, $LD_LIBRARY_PATH, etc. relativement à ce préfixe, bien sûr.

        Au final l'ensemble du projet et toutes les dépendances seront inclus dans ce préfixe. Tu n'auras alors qu'à compresser le répertoire et envoyer tout ce qu'il y a dedans sur ta machine cible. Puis sur ta machine, tu décompresses où tu veux, et tu mets à jour le PATH et le LD_LIBRARY_PATH. En général, il n'est même pas nécessaire d'avoir les mêmes qu'à la compilation. Je dis "en général" car selon le programme, il est possible que le préfixe de compilation se retrouve dans des fichiers de conf, voire même dans des binaires compilés. Donc ça reste du cas par cas, un peu dangereux, et il est quand même préférable de savoir quel sera le préfixe final. Mais juste savoir le préfixe que tu peux utiliser, ça ne doit pas être si dur à savoir, non?
        Normalement tes admins devraient savoir tout ça ceci dit! Je comprends pas pourquoi tu te retrouves à faire cela si c'est pas ton boulot. Les admins devraient te dire ce dont ils ont besoin. C'est leur boulot.

        je sais que j'aurais un linux 64 bits sans droits d'admin.

        Ça c'est vraiment pas un blem. Sauf si ton programme est censé avoir accès à des ressources systèmes interdites aux utilisateurs (parce que ça peut faire tout pêter, ou bien parce que ça peut donner des infos sur les autres utilisateurs, par ex). Dans ce cas, il te faut être root à un moment donné pour au minimum faire un setuid. Mais la plupart des programmes utilisateurs n'ont pas ce cas d'usage et peuvent tout à fait être installés sans le moindre droit par un utilisateur normal.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Ca marche avec Linux ??

          Posté par freejeff le 21 octobre 2013 à 06:49. Évalué à 1.

          

          merci pour ta reponse.

          le probleme vient du fait que je ne compile qu'une toute petite partie des libs dont j'ai besoin et utilise celles du systeme.
          Hors ce que j'aimerai c'est d'avoir un outil qui permet d'installer toutes les libs systems dont j'ai besoin en local, pour ne pa avoir a tout recompiler en static avec par exemple :
          fftw3
          openmp
          mpi
          tiff
          png
          netcdf
          lapack

          Si l auteur du journal arrive a le faire pour windows, je trouve que ca pourrait etre symopa de se dire :
          je dois trimballer mon programme, il est installe sur mon pc avec les lib du pc, je vais en faire une version ou les libs du pc vont etre telechargees et installees dans un repertoire cible pour la compilation de mon projet.

          Comme il cree un environnement de compilation ou il n'y a rien a changer dans le makefile alors mon port vers un system linux standard vierge de toutes les libs que j'ai cite devient vraiment trivial.
          Par contre si je dois compiler toutes ces libs alors le makefile va devenir bien plus complexe a gerer. Alors je pourrais compiler toutes les libs a la main et faire le lien moi meme avec un outil comme cmake, mais du coup c'est vraiment bien plus long et complexe.

          Je me moque dans un premier temps d'avoir la version la plus parfaite pour mon archi, un bete x86_64 me suffira totalement.

          Alors certes ce n'est pas parfait, il vaut mieux faire une installation propre, mais ca me permet de faire un executable que je peux enmener avec moi pour faire des demonstrations aux chercheurs du domaine tres facilement sur leur pc !

          Si nous faisions le code avec matlab, il suffirait d'utiliser mcc et on aurait une version portable. C'est tout de meme un vrai probleme de linux par rapport a windows et du libre par rapport au proprio. Je n'ai pas a obliger des gens a installer tout un tas de lib pour utiliser notre code. En fait on a fait la betise de ne pas utiliser des libs static des le debut, vu le temps aue cela prend de passer de dynamic a static, et le manquue d'outils pour le faire, je ne ferais plus cette erreur, a moins qu'une solution de ce type me facilite la vie !

          Je pense qu'il y a deja eu de nombreux debats avec par exemple Zenitram qui se plaignait de la difficulte de package pour linux. Alors oui,, cela n'a rien a voir avec un packaging pour une distrib, mais ca pernet de tester les softs ailleurs …

          Voila l'idee c'est plus clair comme ca ?

          • [^] # Re: Ca marche avec Linux ??

            Posté par Jehan (site web personnel, Mastodon) le 21 octobre 2013 à 07:46. Évalué à 6.

            

            Hors ce que j'aimerai c'est d'avoir un outil qui permet d'installer toutes les libs systems dont j'ai besoin en local, pour ne pa avoir a tout recompiler en static avec par exemple

            Mais je pige pas vraiment non plus pourquoi tu penses avoir besoin de recompiler pour des libs statiques. Les paquetages de développement sur les distribs que je connais fournissent aussi les libs statiques. Pas seulement les dynamiques. C'est le cas sur ma Linux Mint (donc Ubuntu aussi). Je suis à peu près sûr que c'était aussi le cas sur ma Mageia. Etc.

            Si l auteur du journal arrive a le faire pour windows

            L'auteur du journal, c'est moi, au passage.

            je dois trimballer mon programme, il est installe sur mon pc avec les lib du pc, je vais en faire une version ou les libs du pc vont etre telechargees et installees dans un repertoire cible pour la compilation de mon projet.

            On appelle ça le gestionnaire de paquets sous Linux! :-p Plus sérieusement, je comprends pas trop le problème. J'ai l'impression que tu dis que j'arrive à faire un truc pour Windows avec crossroad qu'on n'a pas pour Linux en temps normal. Mais c'est l'inverse. On a le gestionnaire de paquet pour Linux. Et avec crossroad, je ne fais que reproduire le concept pour Windows. Mais pour Linux, ben ça existe déjà! Rien à reproduire!

            Par contre si je dois compiler toutes ces libs alors le makefile va devenir bien plus complexe a gerer.

            Es-tu en train de dire que tu écris ton Makefile entièrement à la main? Si c'est le cas, ne cherche plus. Je crois qu'on a trouvé ton problème. Faire un Makefile entièrement à la main n'est plus une option viable pour n'importe quel projet qui dépasse le jouet. Tu fais ça au début pour apprendre ce qu'est un Makefile, mais ensuite pour un vrai projet, avec des dépendances, tu génères ton Makefile avec des outils qui vont tout faire pour toi. Que ce soit les autotools, cmake, qmake, ou quoi que ce soit. On n'écrit pas de code spécifique pour gérer des libs statiques et pourtant les Makefile générés par les autotools/cmake sont capable de générer soit du dynamique, soit du statique, soit les deux à la fois!

            Si nous faisions le code avec matlab, il suffirait d'utiliser mcc et on aurait une version portable.

            Oulah! Tu parles complètement d'autre chose là. Ça fait des années que j'ai plus touché matlab, mais au dernières nouvelles, il s'agit de code interprété. Tu peux aussi bien écrire du code matlab sur Linux si tu veux, et il sera tout aussi portable. Pareil pour n'importe quel language interprété. Ça n'a rien à voir avec des problèmes de chaîne de compilation, ni avec l'OS ou le fait que c'est proprio ou libre.

            C'est tout de meme un vrai probleme de linux par rapport a windows et du libre par rapport au proprio.

            Franchement je crois bien que s'il y a un point où on n'a pas à rougir, c'est notre chaîne de compilation et les divers outils de gestion de projets. C'est pas pour rien qu'on cherche à cross-compiler sur Linux pour Windows, même si on a accès à un Windows (en VM par ex pour moi): car c'est 100 fois plus simple sous nux!

            Je pense qu'il y a deja eu de nombreux debats avec par exemple Zenitram qui se plaignait de la difficulte de package pour linux

            Je ne suis pas la moindre des discussions sur linuxfr, mais je me demandes si tu ne cites pas là un tout autre sujet, qui est celui des gestionnaires de paquetage, pas la chaîne de compilation.

            En fait on a fait la betise de ne pas utiliser des libs static des le debut,

            Franchement je crois que votre bêtise fut d'écrire apparemment vos Makefile à la main (si j'arrive bien à lire entre tes lignes. Désolé si je me plante). Je vous conseille de passer un peu de temps pour réécrire la chaîne de compilation de votre projet. Lisez des tutos cmake ou autotools, et choisissez l'un des deux (ou un autre, je suis pas sectaire).

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Ca marche avec Linux ??

              Posté par freejeff le 21 octobre 2013 à 08:09. Évalué à 2.

              

              En fait tu as certainement raison sur toute la ligne.

              Nous ne sommes pas informaticien, (mecano pour moi) et n'avons jamais vraiment eu des cours de genie logiciel. C'est de plus assez dur a trouver sur linux (dans les formations du DIF).

              Tu va trouver des cours pour t'apprendre le c++ le CUDA, … mais pas la gestion de l'ingenierie qui va avec.

              Donc ce aue l'on a fait c'est :

              utiliser cmake comme outil de generation de makefile.

              Cmake utilise des fichier findLIBTOTO.cmake pour trouver les libs donc quand il n'y en avait pas pour certaines libs on les a crees.

              Par contre je ne savais pas que les libs existaient en statique dans les distributions mais j'ai regarde le "Ubuntu Policy Manual" et j'ai vu qu'ils mettaient les .a dans les packages de dev.

              Comme tu le vois c'est clairement un probleme d'incompetence de ma part …

              Mais du coup si je comprends bien, je dois juste copier les libs statique utilisees dans mon projet dans un prepertoire que j'emmenerai avec moi et dire a cmake ou elle sont.

              Pour matlab mcc c'est pour MATLab C Compiler, ca permet de distribuer ton travail matlab pour quelqu'un qui ne l'a pas et en plus ca optimise les boucles un peu complexe.

              L'idee chez nous est de virer petit a petit tout ce qui n'est pas open des devs ou je participe. Donc virer Matlab est un debut, mais c'est vrai que cette possibilite de rapidement faire un outil que tu deplois n'importe ou sans avoir de dependance est vraiment plaisante.

              Donc merci pour l'aiguillage, je pense que j'ai suffisament de pistes pour rendre notre code transportable pour faire des essaias dans d'autres labos.

              Desole d'avoir polluer le fil de discussion …

            • [^] # Re: Ca marche avec Linux ??

              Posté par spider-mario le 26 octobre 2013 à 21:01. Évalué à 1.

              

              Mais je pige pas vraiment non plus pourquoi tu penses avoir besoin de recompiler pour des libs statiques. Les paquetages de développement sur les distribs que je connais fournissent aussi les libs statiques. Pas seulement les dynamiques. C'est le cas sur ma Linux Mint (donc Ubuntu aussi). Je suis à peu près sûr que c'était aussi le cas sur ma Mageia. Etc.

              Juste pour information, Arch Linux est en train d’éliminer toutes celles qui ne sont pas nécessaires.

  • [^] # Re: Ca marche avec Linux ??

    Posté par scorpio810 (site web personnel) le 20 octobre 2013 à 13:51. Évalué à 1.

    

    Salut,

    ça m'intéresserai bien avec qmake et les libs libqt4-dev etcc

    • [^] # Re: Ca marche avec Linux ??

      Posté par Jehan (site web personnel, Mastodon) le 20 octobre 2013 à 16:05. Évalué à 2.

      

      Salut,

      Ben je prends tout patch pour le support de qmake dans crossroad. Si tu me le fais, je l'intègre! :-)

      Ou alors faudra attendre que je tombe sur un projet qmake que je veuille cross-compiler (mais ça peut prendre très longtemps! J'utilise pas qmake pour mes projets, et je tombe rarement sur des projets qmake).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• # Cross compiler vers du matériel différent ?

  Posté par chonyi le 20 octobre 2013 à 14:21. Évalué à 0.

  

  Une question de noob encore, mettons que :

  • j'ai un proc double coeur x86 avec une FPU et un GPU Y
  • j'ai une lib que je peux optimiser pour:
    • le nombre de proc (ou le nombre de coeur), détection par l'instruction OpenMP omp_get_num_procs())
    • le type d'instructions (s'il y a SSE, NEON, AVX, etc.), détection avec des #ifdef
    • le nombre de FPU (là je m'aventure un peu, même si j'imagine que ça correspond au nombre de proc ?)
    • les caractéristiques du GPU (par OpenCL)
  • je veux compiler ma lib pour le smartphone Z qui a un proc ARM double coeur, une FPU, un GPU de tel type, etc.

  J'imagine que c'est pas aussi simple que rajouter quelques options à un environnement crossroad, mais est-ce que c'est envisageable, souhaitable, infaisable, hors contexte ?

  Merci !

  • [^] # Re: Cross compiler vers du matériel différent ?

    Posté par Jehan (site web personnel, Mastodon) le 20 octobre 2013 à 16:02. Évalué à 4.

    

    Salut,

    Même lorsqu'on compile pour sa propre plateforme, on compile très rarement pour une architecture très précise. En gros, ceux qui font cela sont par exemple les gens sous Gentoo, ou bien des fous de l'optimisation. J'imagine aussi que dans le monde des jeux vidéos ultra-performants (c'est juste une hypothèse, je sais pas s'ils font vraiment ça), les dévs vont compiler plusieurs versions pour les processeurs et CG majeurs, et vont embarquer ainsi toutes ces versions alternatives dans leur installeur qui détectera en temps réel et installera une version optimisé si possible (une version plus générique sinon).

    Mais à part ça, les développeurs se contentent de fournir deux versions pour x86 (une 32 et une 64-bit), pareil pour Mac, et pour Linux, etc. (ça fait déjà pas mal de versions!)
    Et encore certains se contentent de 32-bit en se disant que de toutes façons, tous les OS 64-bit ont un layer de compatibilité 32-bit. Voire même livrent le binaire Win pour Nux en embarquant Wine. On a tous vu ça, n'est-ce pas?

    Donc ./configure, même si la cible est ta propre plateforme, va fournir par défaut un binaire générique (c'est à dire un code non optimisé pour le plus petit dénominateur commun similaire à ta machine, par ex "tout processeur x86 32-bit"), et non un binaire optimisé pour ton proc exact. Parce que c'est ce que la plupart des gens veulent. Si tu veux du code spécifique, tu dois spécifier explicitement l'architecture à ton compilateur. Par exemple, fait un man gcc. Regarde des options du type -march, -mcpu, -mtune, déjà. Et encore ça c'est de la petite optimisation. Après chaque architecture a son propre lot d'options spécifiques pour aller plus loin, activer ou non des fonctionnalités, etc. Normalement tu vas activer de telles options en modifiant ton CFLAGS pour C, CXXFLAGS pour C++, etc.
    J'en dirais pas plus parce que je suis loin d'être un pro de l'optimisation. Le plus loin que j'ai fait, c'est quand j'utilisais Gentoo, et encore je me contentais de spécifier l'architecture processeur.
    En général, je fais plutôt comme tout le monde: je fais simple et compile générique. :-)

    Donc est-ce que crossroad peut aussi compiler avec des optimisations? Ben j'ai pas testé, mais étant donné que MinGW-w64 se base sur gcc, je pense que oui. J'imagine qu'il suffit de choisir tes options, faire divers CFLAGS pour les diverses architectures particulières que tu veux, puis faire un export CFLAGS="-some-great-optimization -another" (tu fais un man gcc et tu fais ton marché). Bien sûr, fait ça avant de commencer à configurer (crossroad configure) et compiler pour que ce soit bien pris en compte.
    En outre je te conseille fortement d'ajouter tes flags l'un après l'autre, reconfigurer, compiler, tester. Avec les optimisations, on peut beaucoup plus facilement casser un binaire (même si a priori, la compilation semble finir bien), ne serait-ce que parce que ce sont des options moins utilisées, donc moins testées, du compilateur.

    Enfin y a pas mal de trucs qui se font à l'exécution, et non pas à la compilation. Par exemple tu nous dis que t'as une fonction pour savoir le nombre de proc. Donc c'est pour changer ton fonctionnement à l'exécution (par exemple décider du parallélisme de ton code en fonction du nombre de proc, etc). Ça n'impacte pas la compilation; et franchement j'ai jamais vu de ma vie un code où on choisit le nombre de cœurs à la compilation, surtout que de nos jours, y a de tout, même dans le grand public! À chaque sortie de ton logiciel, tu le compilerais 50 fois. C'est pas tenable. X-/

    Pareil OpenCL (qu'on utilise aussi dans GEGL, donc dans GIMP) fait du code portable. Si j'ai bien compris (j'ai pas encore touché de code OpenCL, donc il se peut que je dise des bêtises), c'est même l'un des points majeurs d'OpenCL: faire du code portable plutôt que spécifique, tout en permettant de tirer profit du nombre de cœurs à l'exécution, de spécificités de et optimisations pour certains CPU et GPU, etc. Donc pareil, tu gères à l'exécution, pas à la compilation.

    J'espère que ça aide.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Cross compiler vers du matériel différent ?

      Posté par chonyi le 20 octobre 2013 à 19:38. Évalué à 0.

      

      En gros, ceux qui font cela sont par exemple les gens sous Gentoo, ou bien des fous de l'optimisation. J'imagine aussi que dans le monde des jeux vidéos ultra-performants

      Là je suis plus dans une autre catégorie, le calcul scientifique (astronomique en l'occurence). En gros je fais quelques dizaines de milliers de fois l'opération X += A * cos(B * T + C).

      Je ne vais pas répondre point par point mais tu as tout à fait raison quand tu dis qu'OpenMP et OpenCL vont faire ça automatiquement à l'éxécution, je n'avais pas les idées très claires là-dessus, ça va mieux donc merci !

      Là l'idée est d'utiliser les extensions vectorielles de gcc (donc avec une bonne abstraction matérielle), et donc de compiler automatiquement le bon code assembleur, que ce soit avec des instructions NEON, SSE, AVX, etc. par contre il faut qu'à la compilation, je lui dise que pour tel environnement (ex : windows sur smartphone) il prenne les instructions NEON, pour d'autres (windows sur pc), il prenne les SSE, etc. quand Je n'ai pas les idées très claires là-dessus mais c'est l'idée… Le top serait de pouvoir faire :

      • OpenCL pour que ça tourne sur le GPU
      • OpenMP qui va diviser en plusieurs parties :
        • autant de parties qu'il y a de FPU, ça tourne en parallèle sur toutes
        • plus autant de parties qu'il y a de coeurs, avec les instructions SSE, avec en bonus la vectorisation qui double les performances

      On passerait de la minute actuelle à moins de 20s à mon avis… mais il faut arriver à le faire de façon portable… (et je n'ai pas bien cherché mais je n'ai pas trouvé d'exemple de code faisant tourner en parallèle du FPU et du SSE sans passer par l'assembleur…) mais je dis peut-être des bêtises… Et ça commence à être hors-sujet !

      • [^] # Re: Cross compiler vers du matériel différent ?

        Posté par Jehan (site web personnel, Mastodon) le 21 octobre 2013 à 06:37. Évalué à 4.

        

        donc de compiler automatiquement le bon code assembleur, que ce soit avec des instructions NEON, SSE, AVX, etc. par contre il faut qu'à la compilation, je lui dise que pour tel environnement (ex : windows sur smartphone) il prenne les instructions NEON, pour d'autres (windows sur pc), il prenne les SSE, etc. quand Je n'ai pas les idées très claires là-dessus mais c'est l'idée…

        À la compilation, tu peux pas configurer ce que le binaire fera à l'exécution. La seule chose que tu peux faire, c'est compiler plusieurs versions de ton logiciel, et installer chaque version sur la bonne machine. Chaque binaire aura un code machine différent (soit parce que le code source est différent et sélectionné par des commandes pré-processeur, soit parce que le compilateur va générer un code machine différent pour le même code source).

        Si tu veux un seul binaire commun qui fait diverses choses selon l'architecture précises, on revient sur des librairies d'abstraction, comme OpenCL et compagnie avec une logique dans le code. Faut pas que tu mélanges les deux. C'est complémentaire.

        Et de manière général, il n'y a pas de magie. Le multi-tâche (threading, multi-proc, etc.), c'est dans le code. Ça peut être plus ou moins encapsulés dans des librairies haut niveau, mais ça reste au dév de créer la logique. Une option du compilateur pour créer du code parallèle à partir de code linéaire, ça n'existe pas.
        Donc ce genre de choses n'a vraiment rien à voir avec la compilation (bien sûr y a des options de compilation en rapport avec le multi-thread, mais c'est pas pour transformer magiquement ton code), et donc avec crossroad.

        La seule chose qui a un rapport, c'est quand tu parles de générer des sets d'instructions plus précis que juste x86 32/64-bit. Comme dit plus haut, fais un man gcc. Et fais une recherche avec tes mots clés. Je trouve des trucs pour NEON (-mfpu=neon), plein de mentions de SSE (plein d'options, à toi de choisir lesquelles tu veux), pareil pour AVX. Ça oui, tu peux rajouter ces options dans ton CFLAGS (donc probablement aussi fonctionnel avec crossroad).
        Et encore même pour ça, ça ne signifie pas que le code final va soudainement être parfaitement optimisé. Le compilateur va tenter de générer des codes spécifiques plus performants s'il détecte des schémas connus. Et pour ça les compilos modernes sont très forts et peuvent être plus performants que la plupart des dévs. Mais une machine reste moins intelligente qu'un humain malin. Et il est donc possible que tu puisses optimiser davantage avec du code assembleur (comme il est aussi possible que tu fasses pire que l'optimisation du compilo).

        Pour tout le reste, c'est à toi de bosser et de modifier ton code. ;-)

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.