Est-il conseillé de passer de Cygwin 32bit à Cygwin 64bit?
J'utilise Cygwin (depuis longtemps). Plus précisément, je l'utilise (y compris gcc/g ++) sur Win7 pour le travail de développement. J'ai récemment remarqué qu'il existe maintenant un version 64 bits .
Je n'ai pas de besoin spécifique qui nécessite que je fasse la transition vers 64 bits, mais je me demandais si je devais le faire quand même. Est-ce conseillé? Quels sont les avantages et inconvénients? Existe-t-il des problèmes de dépassement d'arc connus lors de la transition?
Il était une fois, Cygwin 64 bits manquait de nombreux packages présents dans Cygwin 32 bits, mais aujourd'hui la liste de ces packages est assez court. Étant donné que c'était la dernière raison importante de créer de nouvelles installations Cygwin 32 bits sur des systèmes Windows 64 bits, il est peu probable que vous ayez une bonne raison de le faire aujourd'hui.
Le plus grand avantage de l'utilisation de Cygwin 64 bits est l'accès à de plus grandes quantités de mémoire. L'avantage se présente de deux manières très différentes:
De nombreux programmes Cygwin utiliseront autant de RAM que vous pouvez leur en donner).
Si vous utilisez la version Cygwin de R avec de grands ensembles de données, par exemple, vous devez passer à Cygwin ASAP 64 bits car R veut charger le l'ensemble des données dans la RAM, donc l'utilisation de Cygwin 32 bits sur une machine 64 bits limite artificiellement ce que R peut accomplir sous Cygwin.
La façon dont Cygwin traite les DLL face aux appels
fork()nécessite qu'ils soient chargés à une adresse mémoire fixe.(Il s'agit du mécanisme
rebase, qui s'exécute normalement automatiquement à la fin de chaque exécution dusetup.exeDe Cygwin.)Une conséquence de cela est qu'il était possible dans Cygwin 32 bits d'installer autant de packages que
rebasemanquait d'espace d'adressage en essayant de leur donner toutes les adresses de chargement uniques. La taille exponentiellement plus grande de l'espace d'adressage 64 bits élimine désormais cette possibilité, à toutes fins pratiques.
Cygwin 64 bits peut également être un peu plus rapide, dans certains cas.
Vous pouvez installer et exécuter les deux versions de Cygwin en même temps. Vous pouvez même avoir une fenêtre MinTTY pour chacun en même temps. Néanmoins, il est préférable de les traiter comme des mondes séparés, car les deux Cygwins sont fondamentalement incompatibles . Vous aurez des ennuis si vous essayez de les faire interagir.
Cette incompatibilité fondamentale peut vous mordre de plusieurs manières:
Même si un programme Cygwin 64 bits peut lancer un programme Cygwin 32 bits et vice versa, plusieurs mécanismes inter-processus ne fonctionneront pas à travers cette frontière: mémoire partagée POSIX, passage de descripteur de fichier,
getppid(2).. .Même certaines choses que vous ne pensez pas être des processus croisés échoueront lorsque vous essayez de faire interagir deux Cygwins différents. Une grande partie du contenu de
/procDe Cygwin provient de la DLL, par exemple, donc il sera différent entre deux Cygwins, même s'ils s'exécutent simultanément sur la même machine.Supposons que vous vouliez partager
/usr/localEntre les Cygwins afin de ne pas avoir à avoir deux copies de tous les logiciels que vous avez créés à partir de la source.Après avoir lu le premier élément ci-dessus, vous vous rendez compte que vous ne pouvez pas partager
/usr/local/binOu/usr/local/lib.Après y avoir réfléchi, vous décidez que vous voulez juste partager
/usr/local/srcAfin que vous n'ayez pas au moins à avoir des arbres source en double. Vous aurez toujours des problèmes si vous construisez l'un de ces programmes dans l'arborescence source, comme cela est typique. (c'est-à-dire./configure && make && make install)Ceci arrive pour deux raisons:
Les binaires générés (
*.o,*.so,*.a,*.exe...) seront incompatibles entre les deux Cygwins, donc à moins que vousmake cleanlors du basculement entre Cygwins, ils seront laissés pour compte, ce qui créera de la confusion.Même si vous vous souvenez de
make clean, La sortie de./configureSous chaque Cygwin sera probablement différente, donc essayer de construire un programme sous Cygwin 64 bits qui a été configuré sous Cygwin 32 bits (ou vice versa) pourrait échouer.
Il existe plusieurs façons de sortir de ce piège:
Abandonnez également le partage de
/usr/local/src.N'oubliez pas de
make clean && ./configureChaque fois que vous changez de Cygwins.Build build out-of-tree séparément pour chaque variante de Cygwin.
C'est plus propre, plus rapide et plus fiable que l'option précédente, mais tous les arbres sources ne sont pas configurés pour permettre cela.
Si vous n'avez pas de bonnes raisons de supporter de tels problèmes, installez une version ou l'autre, pas les deux.
Si vous disposez d'une configuration Cygwin 32 bits fonctionnelle et que vous n'avez pas besoin des avantages de Cygwin 64 bits, vous n'avez pas besoin de penser que vous devez la remplacer par une installation 64 bits. Cygwin 32 bits ne partira pas de si tôt.
En même temps, si je configurais une nouvelle boîte Windows 64 bits, j'installerais Cygwin 64 bits dessus, sauf si je savais à l'avance qu'il n'y avait pas de package porté dont j'avais besoin, et je n'étais pas prêt à faire le port moi-même. C'est stable et presque complet.
Corinna Vinschen, co-développeur principal de Cygwin , a déclaré ce qui suit, dans le cadre des Notes de version Cygwin 1.7.25 :
À PROPOS DE LA LIBÉRATION DE 64 BITS
Ce n'est que la quatrième version officielle de Cygwin qui est publiquement disponible en tant que version 64 bits pour les systèmes Windows AMD64, elle est donc encore assez nouvelle.
À l'heure actuelle, la distribution Cygwin 64 bits n'est pas livrée avec autant de packages que la version 32 bits, mais elle est aussi stable que la version 32 bits, et plus de packages seront disponibles au fil du temps.
Si vous exécutez déjà une version 32 bits de Cygwin sur des machines Windows 64 bits, vous pouvez continuer à le faire. Si vous prévoyez une nouvelle installation de Cygwin sur une machine Windows 64 bits, pensez à utiliser la nouvelle version Cygwin 64 bits, sauf si vous avez besoin de certains packages qui ne sont pas encore disponibles dans la version 64 bits.
L'autre problème avec la "mise à niveau" vers 64 bits est qu'il n'y a pas, AFAIK, un moyen de réinstaller automatiquement la même liste de packages que vous aviez dans l'installation 32 bits, vous devrez donc faire une liste minutieuse des packages installés et soigneusement les vérifier tous dans la nouvelle installation juste pour revenir à où vous étiez avant de réinstaller.
Il y a de gros avantages avec Cygwin x64. L'un d'eux est la meilleure gestion de la mémoire. J'ai expérimenté beaucoup de address already in use, ou fork: retry: Resource temporarily unavailable qui m'a obligé à exécuter un rebaseall plusieurs fois par jour.
Avec Cygwin x64, je n'ai jamais eu de problèmes comme celui-ci.
Installez les deux. Cela ne prend pas beaucoup de temps ou d'espace disque, et certains packages ne sont pas disponibles pour cygwin64. (Mettez-les dans différents répertoires!)
Je ne sais pas si sqlite3 dans cygwin64 peut indexer des bases de données de taille supérieure à 4G, mais je sais que sqlite3 dans cygwin32 ne peut pas, et sqlite3 dans Linux 64 bits.
cygwin64 n'a toujours pas pdftk (le PDF toolkit).
Pas assez de réputation pour commenter la réponse sélectionnée, alors voici:
Qu'en est-il de l'installation de Cygwin64 dans c:\cygwin (via setup-x86_64.exe), effectuez une installation secondaire de Cygwin32 dans c:\cygwin32 (via setup-x86.exe), puis ajouter /cygdrive/c/cygwin32/<for_each_of_the_bin_dirs> à la fin de $ PATH?
Cela devrait exécuter les applications 64 bits par défaut, mais permettre d'appeler des applications 32 bits si la version 64 bits n'est pas présente.
Il serait utile que setup-x86_64.exe a été en mesure de présenter une liste unifiée de toutes les applications Cygwin, et d'effectuer l'installation 32 bits uniquement en cas de besoin (avec une fenêtre contextuelle suggérant de faire un port 64 bits).