J'essaye de reconstruire des packages Alpine sur un hôte x86_64 pour une cible armhf . Pour autant que je sache, la bonne façon de procéder est de cloner https://github.com/alpinelinux/ aports et exécutez scripts / bootstrap.sh armhf pour créer un environnement chroot qui peut ensuite être utilisé pour la compilation croisée des paquets. Jusqu'à présent, j'ai:
$ {HOME} / packages / main à /etc/apk/repositories abuild-keygen -a cp $ {HOME} /. abuild / *. pub / etc / apk / keys Mais le script d'amorçage échoue toujours avec:
c4a5a8fbf023:~/aports$ scripts/bootstrap.sh armhf
>>> bootstrap-armhf: Building cross-compiler
>>> binutils-armhf: Package is up to date
>>> gcc-armhf: abuild 3.2.0-r0
>>> gcc-armhf: Checking sanity of /home/builder/aports/main/gcc/APKBUILD...
>>> WARNING: gcc-armhf: g++ should not be in makedepends
>>> gcc-armhf: Analyzing dependencies...
ERROR: unsatisfiable constraints:
.makedepends-gcc-armhf-0:
masked in: cache
satisfies: world[.makedepends-gcc-armhf]
musl (missing):
required by:
musl-dev (missing):
required by:
>>> ERROR: gcc-armhf: all failed
>>> gcc-armhf: Uninstalling dependencies...
musl et musl-dev sont paquets construits pour armhf et se trouvent dans ${HOME}/packages/main/armhf.
Quelqu'un peut-il m'indiquer la bonne magie pour que cela fonctionne? Y a-t-il une documentation à ce sujet quelque part que j'ai manquée?
3 Réponses :
Eh bien, j'ai eu la même erreur mais je l'ai résolue en procédant comme suit:
1. abuild-keygen -a , puis j'ai sauvegardé ma clé avec le nom mykey et obtenu mes clés (privées et publiques) dans mon répertoire actuel.
2. Ensuite, déplacez simplement mykey.pub dans / etc / apk / keys
3. Ensuite, construisez votre chaîne d'outils de compilation croisée par CBUILDROOT = / chemin / vers / buildroot ./scripts/bootstrap.sh armhf et encore une chose, ne créez pas votre CBUILDROOT directement ou manuellement, laissez simplement bootstrap script le créer.
Faites-moi savoir si vous avez encore échoué.
abuild-keygen -a -i and install sudo
La réponse au code seul est correcte, mais si vous y ajoutez des commentaires, votre réponse sera plus facile à comprendre et à trouver!
Lorsque j'ai rencontré ce problème, c'est parce que dans mon empressement, j'ai exécuté le script d'amorçage avant de configurer ma clé de signature de paquet. Cela signifiait que la racine système d'amorçage n'était pas remplie avec la clé de signature du package car le programme d'amorçage ne le copie que lors de son exécution initiale , ce qui a conduit aux messages d'erreur indiqués ci-dessus. La copie manuelle de la clé dans ~ / sysroot-armhf / etc / apk / keys devrait résoudre le problème.
Je cherche à essayer, avez-vous déjà trouvé une solution?
@ Rich Non. J'ai fini par utiliser deux conteneurs docker; l'un basé sur alpine 3.9 amd64 où je construis et héberge un compilateur croisé pour construire les binaires, l'autre basé sur alpine 3.9 armhf où je construis les paquets. Il est possible de le faire dans un seul conteneur en utilisant qemu et un gcc armhf natif, mais c'est horriblement lent, du moins pour mon cas. Je construis des exécutables de golang, et la compilation croisée prend quelques minutes contre plus de dix heures sous qemu.
Merci Tom. J'ai vraiment pris Alpine pour ses nombreuses fonctionnalités utiles, mais la documentation n'en fait pas partie.
Pour info, nous avons également constaté que l'utilisation de Docker et de QEMU rend cela beaucoup plus facile que le simple QEMU de manière native. "FROM multiarch / alpine: arm64-v3.9" Au moins pour une seule cible, c'est plus rapide.