Posté par benja .
En réponse au message Cryptsetup: help !!!.
Évalué à 1.
Dernière modification le 05 avril 2016 à 01:28.
En gros le préfix ne sert qu'au configure.
Le configure va typiquement créer un fichier config.h et divers Makefiles. Dans le config.h seront définies des macro du préprocesseur qui permettent à la compilation de connaître la "configuration". Par exemple la macro HAVE_MATH_H sera définie si le script configure a détecté le fichier math.h. Tu auras aussi des constantes utilisées par ton programme, tel que les chemins d'accès. Tout ça c'est gèré par autotools, voir https://github.com/mbroz/cryptsetup/blob/master/configure.ac .
Le préfix va aussi aider à détecter les bonnes bibliothèques. mais dans le cas de la cross compilation, ça ne peut pas marcher car tes bibliothèque cross-compilées ne sont pas installées dans un répertoire standard. I.e. tu veux que ton préfix vaut /usr mais tes bibliothèques sont installées dans /cross/usr/lib/... Ça peut parfois marcher si t'arrives à passer --sysroot=/cross dans les CFLAGS et LDFLAGS (y a peut-être une autre méthode...), Dans ce cas là, le compilateur va traduire de manière transparente les chemins de recherche. En gros les deux approches sont possibles, cela dépends surtout de comment est prévue ta toolchain.
Deuxième point, on peut voire dans ce configure.ac que cryptsetup utilise pkg-config. Là, le prefix joue probablement une influence seulement si tu ne spécifie pas toi-même un chemin de recherche pour pkg-config. Si tu lance ./configure --help, tu devrais retrouver l'option qui te permette de spécifier le chemin de recherche des fichiers pkg-config. Ce sont ces fichiers .pc qui vont dire où sont les bilbiothèques à installer.
Bref, oublie le préfix pour l'instant. Relance ./configure et fais super attention aux valeurs qu'il donne pour
1) le compilateur. normalement ça serait un truc du genre gcc=/tonsdk/bin/arm-linux-gnueabihf-gcc
2) les chemins des bibliothèque détectées.
Vais je directement retrouver mon executable cryptsetup sur la cible dans ce cas la ?
non. le configure va substituer le préfix dans les règles du Makefile, ce qui peut avoir (ou non) une incidence lors du "make install". Mais jamais cela ne va faire une copie via ssh ou que sais-je... (c'est théoriquement pas impossible, mais personne ne s'amuse à le faire).
--enable-static
ok ça c'est bon.
Est ce normal' que j'arrive a lancer cryptsetup depuis mon hote?
Ça dépend... ;-) Il y a moyen d'utiliser qemu avec bin-fmt pour pouvoir lancer de manière transparente un programme d'une autre architecture sous linux. Dans ton cas, cela me semble peu probable que tu aies configuré ton système de la sorte. Si tu lance le programme "file" sur ton binaire (ou "objinfo" ou readelf...) tu seras fixé sur l'architecture de ton binaire.
Et une dernière option, comme la précédente tu fais un chroot et tu le partage via nfs pour ensuite faire le chroot sur ton Rpi. Ça sera probablement plus rapide qu'avec qemu et sans bug du à la cross-compilation ou à qemu.
[^] # Re: Le soucis c'est ?
Posté par benja . En réponse au message Cryptsetup: help !!!. Évalué à 1. Dernière modification le 05 avril 2016 à 01:28.
En gros le préfix ne sert qu'au configure.
Le configure va typiquement créer un fichier config.h et divers Makefiles. Dans le config.h seront définies des macro du préprocesseur qui permettent à la compilation de connaître la "configuration". Par exemple la macro HAVE_MATH_H sera définie si le script configure a détecté le fichier math.h. Tu auras aussi des constantes utilisées par ton programme, tel que les chemins d'accès. Tout ça c'est gèré par autotools, voir https://github.com/mbroz/cryptsetup/blob/master/configure.ac .
Le préfix va aussi aider à détecter les bonnes bibliothèques. mais dans le cas de la cross compilation, ça ne peut pas marcher car tes bibliothèque cross-compilées ne sont pas installées dans un répertoire standard. I.e. tu veux que ton préfix vaut /usr mais tes bibliothèques sont installées dans /cross/usr/lib/... Ça peut parfois marcher si t'arrives à passer --sysroot=/cross dans les CFLAGS et LDFLAGS (y a peut-être une autre méthode...), Dans ce cas là, le compilateur va traduire de manière transparente les chemins de recherche. En gros les deux approches sont possibles, cela dépends surtout de comment est prévue ta toolchain.
Deuxième point, on peut voire dans ce configure.ac que cryptsetup utilise pkg-config. Là, le prefix joue probablement une influence seulement si tu ne spécifie pas toi-même un chemin de recherche pour pkg-config. Si tu lance ./configure --help, tu devrais retrouver l'option qui te permette de spécifier le chemin de recherche des fichiers pkg-config. Ce sont ces fichiers .pc qui vont dire où sont les bilbiothèques à installer.
Bref, oublie le préfix pour l'instant. Relance ./configure et fais super attention aux valeurs qu'il donne pour
1) le compilateur. normalement ça serait un truc du genre gcc=/tonsdk/bin/arm-linux-gnueabihf-gcc
2) les chemins des bibliothèque détectées.
non. le configure va substituer le préfix dans les règles du Makefile, ce qui peut avoir (ou non) une incidence lors du "make install". Mais jamais cela ne va faire une copie via ssh ou que sais-je... (c'est théoriquement pas impossible, mais personne ne s'amuse à le faire).
ok ça c'est bon.
Ça dépend... ;-) Il y a moyen d'utiliser qemu avec bin-fmt pour pouvoir lancer de manière transparente un programme d'une autre architecture sous linux. Dans ton cas, cela me semble peu probable que tu aies configuré ton système de la sorte. Si tu lance le programme "file" sur ton binaire (ou "objinfo" ou readelf...) tu seras fixé sur l'architecture de ton binaire.
Bon je remets un couche avec buildroot. Amha tu vas gagner pas mal de temps. Au pire tu n'es pas obligé d'utiliser le rootfs (image SD), tu peux te contenter de copier les binaires qui devront se retrouver quelque part dans un répertoire build. Ça supporte visiblement bien raspberrypi <3:
https://github.com/buildroot/buildroot/tree/master/board/raspberrypi
et il y a un paquet cryptsetup
https://github.com/buildroot/buildroot/blob/master/package/cryptsetup/cryptsetup.mk
Sinon une autre option, c'est de te faire un chroot, armv6 raspbian pour Rpi 1&2, armv7 debian armhf pour le Rpi 3, que tu lances via qemu+binfmt. Ensuite tu fais une compilation "standard" dedans. C'est juste assez lent... cf. https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach
Et une dernière option, comme la précédente tu fais un chroot et tu le partage via nfs pour ensuite faire le chroot sur ton Rpi. Ça sera probablement plus rapide qu'avec qemu et sans bug du à la cross-compilation ou à qemu.