Posté par benja .
En réponse au message Cryptsetup: help !!!.
Évalué à 1.
Dernière modification le 04 avril 2016 à 18:26.
Le "prefix" sert généralement à trois choses: 1) enregistrer en dur dans ton programme où il va être installé et où il peut rechercher ses resources, documentation, etc. (p.e. une icone dans "$prefix/share/icons/monprogramme.png"). 2) au moment de faire "make install", l'endroit où vont être installés le programme fraichement compilé et ses resources 3) au moment du configure, déduire l'endroit où sont installés les dépendances/bibliothèque/includes.*
Bref dans ton cas, ça n'a pas beaucoup d'importance, car:
1) cryptsetup n'a pas l'air d'utiliser un fichier de configuration cannonique (tu spécifies tout sur la ligne de commande)
2) tu ne veux surtout pas installer sur le système qui compile. Sauf éventuellement si tu veux faire un staging afin de faire facilement une archive à transfèrer (dans ce cas cf. mon précédent commentaire, il faut que le préfix corresponde à l'endroit où tu veux l'installer sur la cible + le buildsystem doit supporter quelque chose de similaire à un DESTDIR qui va servir de "super" préfix).
3) tu as déja du règler le problème pour réussir à compiler - tu linke en statique - tes libairie seront installées dans un répertoire connu par le linker dynamique (/etc/ld.so.conf sous linux...) - tu cross compile, tu as déja du patcher le build-system pour avoir quelque chose de potable (barrer la mention inutile).
Illustration du point 3: dans ton cas il se pourait que ce soit gpgme. Généralement tu peux souvent "overrider" cela avec un argument de type --with-gpg-error=/usr/local ou bien encore avec un ac_XXX=valeur (regarde la gueule du config.log pour avoir le nom de la variable). Généralement cela marche bien dans le cas non-cross compilation. Par contre, dans le cas de la cross-compilation, c'est parfois plus compliqué car le path des bibliothèque que tu linke n'est pas le même que le path sur la cible finale, ce qui peut poser problème lorsque la dite bibliothèque n'est pas installée dans un endroit standard (cf. encore le ld.so.conf, LD_RUN_PATH et compagnie, man ld.so pour les détails). Si tu compiles en statique tu n'auras pas ce problème bien entendu. Ça peut même être plus intéressant si tu as peu de programmes qui utilisent la même bibliothèque car le code non utilisé va être supprimé. C'est pourquoi busybox lie en statique une libc dans un seul binaire, comme ça seul les objets de la libc vraiment utilisés sont repris. Par contre si tu as beaucoup de programmes différents, ben ce gain de place disparait pour devenir négatif. Bref à toi de voir...
À part cela, as-tu trouvé ton binaire et arrives-tu à le lancer sur ta cible ? Car amha le plus simple pour arriver à te faire progresser c'est d'y aller pas à pas pour que tu comprennes bien comme cela fonctionne...
Pour conclure sur buildroot, c'est une sorte de méta systeme de build, un peu comme portage de gentoo si tu connais. Ça compile toutes les dépendances de "paquets" que tu peux sélectionner via une interface de configuration et au finale ça peut générer un filesystem complet voir même une image à flasher. Ça supporte plus que probablement d'utiliser une toolchain "custom" à la place d'en construire une, c'est prévu pour être relativement facilement modifiable. En fonction de ce que tu veux faire, cela peut être intéressant d'investir en compétences là dedans, histoire de gagner du temps par la suite. Il y a d'autres outils similaire à buildroot, je n'en connais personnellement aucun, à part le truc de openwrt qui est basé (si je ne me trompe pas) sur buildroot.
Pour info, c'est quel genre de cible ? Ton kernel c'est un kernel vanilla ? T'as compilé ta toolchain toi même ou bien c'est un truc proprio ? Peut-être que ta board est déja complètement supporté par buildroot (ou qu'un support complèt n'est plus très loin à ajouter)...
*: Pour être complet, généralement tu as la possibilité de modifier spécifiquement certains endroits de recherche qui, par défaut, seraient calculés à partir de "prefix", p.e. (j'invente) --sysconfdir=/etc, --datapath=/opt/share.
[^] # Re: Le soucis c'est ?
Posté par benja . En réponse au message Cryptsetup: help !!!. Évalué à 1. Dernière modification le 04 avril 2016 à 18:26.
Le "prefix" sert généralement à trois choses: 1) enregistrer en dur dans ton programme où il va être installé et où il peut rechercher ses resources, documentation, etc. (p.e. une icone dans "$prefix/share/icons/monprogramme.png"). 2) au moment de faire "make install", l'endroit où vont être installés le programme fraichement compilé et ses resources 3) au moment du configure, déduire l'endroit où sont installés les dépendances/bibliothèque/includes.*
Bref dans ton cas, ça n'a pas beaucoup d'importance, car:
1) cryptsetup n'a pas l'air d'utiliser un fichier de configuration cannonique (tu spécifies tout sur la ligne de commande)
2) tu ne veux surtout pas installer sur le système qui compile. Sauf éventuellement si tu veux faire un staging afin de faire facilement une archive à transfèrer (dans ce cas cf. mon précédent commentaire, il faut que le préfix corresponde à l'endroit où tu veux l'installer sur la cible + le buildsystem doit supporter quelque chose de similaire à un DESTDIR qui va servir de "super" préfix).
3) tu as déja du règler le problème pour réussir à compiler - tu linke en statique - tes libairie seront installées dans un répertoire connu par le linker dynamique (/etc/ld.so.conf sous linux...) - tu cross compile, tu as déja du patcher le build-system pour avoir quelque chose de potable (barrer la mention inutile).
Illustration du point 3: dans ton cas il se pourait que ce soit gpgme. Généralement tu peux souvent "overrider" cela avec un argument de type --with-gpg-error=/usr/local ou bien encore avec un ac_XXX=valeur (regarde la gueule du config.log pour avoir le nom de la variable). Généralement cela marche bien dans le cas non-cross compilation. Par contre, dans le cas de la cross-compilation, c'est parfois plus compliqué car le path des bibliothèque que tu linke n'est pas le même que le path sur la cible finale, ce qui peut poser problème lorsque la dite bibliothèque n'est pas installée dans un endroit standard (cf. encore le ld.so.conf, LD_RUN_PATH et compagnie, man ld.so pour les détails). Si tu compiles en statique tu n'auras pas ce problème bien entendu. Ça peut même être plus intéressant si tu as peu de programmes qui utilisent la même bibliothèque car le code non utilisé va être supprimé. C'est pourquoi busybox lie en statique une libc dans un seul binaire, comme ça seul les objets de la libc vraiment utilisés sont repris. Par contre si tu as beaucoup de programmes différents, ben ce gain de place disparait pour devenir négatif. Bref à toi de voir...
À part cela, as-tu trouvé ton binaire et arrives-tu à le lancer sur ta cible ? Car amha le plus simple pour arriver à te faire progresser c'est d'y aller pas à pas pour que tu comprennes bien comme cela fonctionne...
Pour conclure sur buildroot, c'est une sorte de méta systeme de build, un peu comme portage de gentoo si tu connais. Ça compile toutes les dépendances de "paquets" que tu peux sélectionner via une interface de configuration et au finale ça peut générer un filesystem complet voir même une image à flasher. Ça supporte plus que probablement d'utiliser une toolchain "custom" à la place d'en construire une, c'est prévu pour être relativement facilement modifiable. En fonction de ce que tu veux faire, cela peut être intéressant d'investir en compétences là dedans, histoire de gagner du temps par la suite. Il y a d'autres outils similaire à buildroot, je n'en connais personnellement aucun, à part le truc de openwrt qui est basé (si je ne me trompe pas) sur buildroot.
Pour info, c'est quel genre de cible ? Ton kernel c'est un kernel vanilla ? T'as compilé ta toolchain toi même ou bien c'est un truc proprio ? Peut-être que ta board est déja complètement supporté par buildroot (ou qu'un support complèt n'est plus très loin à ajouter)...
*: Pour être complet, généralement tu as la possibilité de modifier spécifiquement certains endroits de recherche qui, par défaut, seraient calculés à partir de "prefix", p.e. (j'invente) --sysconfdir=/etc, --datapath=/opt/share.