Forum Programmation.c compiler pour un autre système cible

Posté par .
Tags :
3
24
mar.
2011

Bonjour,

Je débute avec le langage vala.
Jusque là tout va bien.

La où ça se corse, c'est que j'ai besoin de faire tourner mon programme sur une autre machine.
J'ai bêtement copier le binaire de A vers B, mais j'ai eu droit à une belle erreur au chargement de librairie partagée glibc (mauvaise version).

Piste n°1: compiler directement sur le système "cible"

J'ai déjà réussi à compiler python 2.7.x sur cette machine, avec support de la zlib qui va bien: je pense donc qu'il y a bien moyen de compiler tout ce qu'il faut, le problème c'est que j'ai une multitude d'incertitudes concernant la compatibilité des différentes version de tous les libs et programmes que j'utilise. Est-ce que je dois tout recompiler (gcc, glibc, libgee, libxml, etc...) ou bien je peux utiliser le gcc 3.4 pour compiler le reste ?
J'avoue que je préfèrerais apprendre à cross compiler directement sur ma machine, ce qui me permettra de produire des binaires pour les systèmes cibles de mon choix sans devoir passer 3h à compiler tous les outils dont j'ai besoin sur ces machines

Piste n°2: cross compilation

Une petite investigation m'a amenée sur la voix de la cross-compilation, malheureusement infructueuse jusqu'à aujourd'hui. J'ai échoué à la première étape: compilation de la toolchain. (outil crosstool)

Piste n°3: statification

J'ai également lorgné du coté de la "statification" des binaires afin que, si j'ai bien compris, ils embarquent les librairies partagées dont ils ont besoin. (outil statifier) Je suis malheureusement également tombé dans une impasse: segfault systématique du binaire static (problème lié à l'option d'allocation aléatoire de mémoire du noyau: sur mon système où j'ai les droits d'admin, j'ai pu désactiver cette fonction (echo 0 > /proc/sys/kernel/randomize_va_space) et le binaire static fonctionne. Je ne dispose pas des droits suffisant sur le serveur...)

Voilà, je pense que la meilleure solution c'est la cross compilation, mais j'avoue que je ne comprends pas tout.

Merci pour votre aide !

Détails techniques:

machine A = ma machine
Ubuntu 10.10 x86
droit admin gcc 4.4.5

machine B = serveur
RHEL 4 AS Update 8
droit user gcc 3.4.6

les dépendances de mon programme:

`$ ldd optim
linux-gate.so.1 =>  (0x005c4000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00110000)
libgee.so.2 => /usr/lib/libgee.so.2 (0x00ee1000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00238000)
librt.so.1 => /lib/librt.so.1 (0x006fc000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00bd1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00ca4000)
libc.so.6 => /lib/libc.so.6 (0x00784000)
libdl.so.2 => /lib/libdl.so.2 (0x00697000)
libz.so.1 => /lib/libz.so.1 (0x00444000)
libm.so.6 => /lib/libm.so.6 (0x00605000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00d8b000)
libpcre.so.3 => /lib/libpcre.so.3 (0x0027b000)
/lib/ld-linux.so.2 (0x00b0b000)`
  • # Use mock Luke !

    Posté par . Évalué à 5.

    http://packages.ubuntu.com/maverick/mock C'est l'outil utilisé par fedora pour générer les chroots de compilation, tu peux utiliser le fichier de config epel-4 comme base.
    1. je génére mon chroot avec tout les paquets dont j'ai besoin sur la machine de développement 2. j'ouvre un shell dans mon chroot mock 3. je compile 4. je balance sur la machine de production

    Si tu fais des paquets RPMS, tu directement passer un src.rpm à mock et il récupérera les dépendances sur les dépôts et construira le paquet tout seul.

    • [^] # Re: Use mock Luke !

      Posté par . Évalué à 4.

      on peut aussi regarder du coté de CDE ; cet outil permet de générer l'équivalent d'un CHROOT contenant l'ensemble des librairies nécessaire à l'exécution du programme.

Suivre le flux des commentaires

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