Installer des programmes 64 bits sur un système d'exploitation 32 bits avec un processeur 64 bits

Je suis curieux. Est-il possible d'installer un programme 64 bits sur un OS 32 bits avec un processeur 64 bits?

J'utilise Linux sur un raspberry pi 3 et j'essaie d'installer une version plus récente de MongoDB:

armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian

Est-il possible d'installer un programme 64 bits sur un OS 32 bits avec un processeur 64 bits?

En principe oui, mais le processeur et l'OS doivent le supporter.

Sur ARMv8, un noyau 32 bits (Aarch32) ne peut pas exécuter des processus 64 bits (Aarch64). Il s'agit d'une limitation du processeur.

Il existe d'autres processeurs qui n'ont pas cette limitation, par exemple, il est possible d'exécuter des processus x86_64 sur un noyau x86_32 sur un processeur x86_64, mais peu de noyaux le prennent en charge, probablement parce que son utilité est limitée (la plupart du temps, vous enregistrez un peu de RAM dans le noyau en le rendant 32 bits). Linux ne le prend pas en charge, mais Solaris le fait.

Vous pouvez conserver votre système d'exploitation 32 bits existant si vous exécutez un noyau 64 bits . Un noyau Linux Aarch64 peut exécuter des processus Aarch32. Raspbian ne prend pas cela en charge, vous devez donc conserver à la fois un système d'exploitation 32 bits et un système d'exploitation 64 bits. Vous pouvez utiliser l'un comme système d'exploitation principal (c'est-à-dire celui qui exécute les services init et système) et l'autre pour exécuter un programme spécifique à l'aide de chroot. Voir Comment exécuter des programmes 32 bits sur un Debian / Ubuntu 64 bits? pour une approche pratique.

Notez que vous devrez installer toutes les bibliothèques requises par le programme 64 bits. Tout processus donné doit être entièrement en 32 bits ou entièrement en 64 bits, vous ne pouvez donc pas utiliser une bibliothèque 32 bits dans un exécutable 64 bits.

À moins d'avoir de bonnes raisons de conserver un système 32 bits, si vous devez exécuter un exécutable 64 bits, il serait plus facile d'installer un système 64 bits.

Notez que la seule chose que les programmes 64 bits peuvent faire mais que les programmes 32 bits ne peuvent pas faire est de traiter plus d'environ 3 Go de mémoire virtuelle, ce qui est d'une utilité limitée sur un système avec 1 Go de RAM. Vous pouvez obtenir des avantages en termes de performances des registres supplémentaires et plus volumineux, mais vous perdrez également les performances des accès à la mémoire supplémentaire.

Sur certaines architectures, oui. Mais pas sur ARM ou x86.

Vous pouvez utiliser QEMU pour émuler un système 64 bits, mais vous ne le souhaitez pas.

Mettez à niveau uniquement votre noyau vers un noyau 64 bits, afin de pouvoir exécuter des binaires 64 bits. Essentiellement, il exécutera toute votre distribution en mode compat 32 bits, et votre seul mongodb 64 bits sera son mode normal.

Mais il ne mérite pas son prix. Mieux vaut passer votre mongodb en 32 bits. Cependant, dans ce cas, il y a une limitation, que votre base de données ne peut pas être plus grande que 2 Go, car elle mappe directement le tout dans la mémoire virtuelle. Si votre base de données est plus grande, seule la mise à niveau du noyau reste. (Merci l'extension @duskwuff!)

Btw, si votre base de données ne veut pas une très grosse charge, ou si vous pouvez utiliser une solution de mise en cache avant elle (par exemple: une autre, mais un mongo 32 bits), alors une émulation cpu pourrait fonctionner. Pour cela, lancez une recherche sur "qemu qemu-system-x86_64". Bien qu'une telle solution aurait probablement un besoin de travail irréalisable et pourrait être considérée comme étrange dans un environnement productif.

À votre place, j'utiliserais du mongo 32 bits si c'est pour ma base de données suffisante, ou un noyau 64 bits si ce n'est pas le cas.

Je dirais que ce n'est pas impossible mais vraiment difficile à gérer. Étant donné qu'un système d'exploitation 32 bits est généralement fourni avec (et accepte) uniquement des fichiers binaires et des bibliothèques 32 bits, vous devez modifier fortement le système pour le faire fonctionner avec des fichiers 64 bits.

Le principal problème auquel vous seriez confronté avec un RPI3 est le manque de noyau 64bits (au moins avec raspbian).

Pour faire court: utilisez des binaires 32 bits et tout ira bien.

ÉDITER :

Si vous souhaitez utiliser un noyau 64bits, vous devrez installer une distribution prenant en charge l'architecture ARM64. Vous devriez jeter un œil à ArchLinux ARM ( ici ), mais il n'est pas entièrement pris en charge.

Les informations que vous recherchez se trouvent au bas de l'onglet d'installation.

Vous pouvez également jeter un oeil à un port Debian officiel , mais il y a toujours de gros problèmes avec le port RPI3, donc c'est à vous de décider si cela en vaut la peine

J'ai utilisé un noyau 64 bits avec un système 32 bits pendant un certain temps (c'est la condition minimale pour exécuter les exécutables 64 bits en natif, plus toutes les bibliothèques 64 bits requises). Je ne le recommanderais pas. Ce qui m'a finalement fait passer à un système 64 bits en gros, c'est la prise de conscience que les en-têtes ALSA, en particulier en ce qui concerne les appels Midi ioctl, n'étaient pas indépendants de la taille, ce qui signifie que les choses compilées en mode 32 bits ne fonctionneraient pas bien avec le noyau 64 bits.

Bien sûr, cela peut être considéré comme un bug à corriger, mais le rythme de développement d'ALSA est presque figé et je ne pouvais pas attendre quelques années pour que le support de la plate-forme mixte soit corrigé (et d'une manière compatible non binaire pour les non mixtes). exécutables) lorsque l'intérêt pour les plates-formes mixtes diminue de toute façon rapidement.

Pour certaines applications, les choses fonctionnent en mode mixte (étonnamment beaucoup en fait), mais si vous faites plus que le partage de base de l'interface avec le noyau, même via des bibliothèques externes, c'est juste trop optimiste.