FoolEcho a écrit :dans le PKGBUILD de gnustep-make-multilib-clang-svn tu appelles build64 dans le package
Oui, c'était justement ce dont j'avais demandé si j'avais le droit ou pas, et là on j'avais conclus par un "oui" en fonction de ta réponse. Le problème, justement, c'est que si tu enchaînes les 2 fonctions build, le make install va installer uniquement la dernière chose a avoir été compilé, donc je n'aurais que la moitié du résultat que je cherche.
FoolEcho a écrit :Juste pour me faire une idée, j'ai construit gnustep-make-multilib-clang-svn comme tu l'as fait... et je ne comprends vraiment pas ton histoire d'avoir le paquet en doublon 32 bits (je vois bien la différence avec les flags 32 bits mais avoir un /usr/bin + usr/bin/linux_386... non franchement, je ne pige pas vu que le paquet officiel gnustep-make n'a qu'une version
![Confused :?](./images/smilies/icon_e_confused.gif)
)
C'est là qu'est toute la magie, tout mon combat. En effet, avec un programme quelconque, en général, il est possible de ne garder que les bibliothèques, et donc de créer simplement des bibliothèques 32 et 64 bits. Mais avec GNUstep, ce n'est pas le cas, c'est pour ça que mes paquets paraissent être un vrai bordel, car si je veux pouvoir avoir une bibliothèque en 32 bits, il est strictement nécessaire que le GNUstep-make "soit en 32 bits" lui aussi. GNUstep-make, visiblement, c'est le composant fondamental qui contient toutes les recettes de fabrication des autres composants de GNUstep.
J'ai aussi mis un moment avant de comprendre ça... Par exemple, en effet, j'ai un /usr/bin et un /usr/bin/linux_386 dans le paquet de GNUstep, pour la simple raison que si j'utilise les outils dans le /usr/bin, j'aurais forcément un composant en 64 bits, alors que si j'utilise les outils dans le /usr/bin/linux_386, j'aurais forcément un composant en 32 bits.
Bref, si tu veux compiler un composant en 32 bits en utilisant les fichiers dans le /usr/bin, d'une part GNUstep-make va te vomir dessus car il va dire «GNUstep-make a été installé avec "clang" or là vous utilisez "clang -m32", donc on ne compile pas». Si on examine de plus près les fichiers dans le /usr/bin et ceux dans le /usr/bin/linux_386, on voit que ce ne sont pas les mêmes, j'ai du m'y plonger un moment pour justement comprendre comment faire pour arriver au résultat final...
FoolEcho a écrit :Je n'ai pas regardé les autres paquets mais ce que je ne comprends pas, c'est pourquoi tu ne fais pas ta version multilib avec juste le build pour x86_64 et que tu ne rajoutes pas les dépendances lib32-truc qui va bien (ok, tu télécharges deux fois, mais côté construction du paquet, c'est nettement plus clair).
![Confused :?](./images/smilies/icon_e_confused.gif)
Car comme je l'ai soulevé, je n'ai pas réussis à faire sortir une bibliothèque 32 bits alors que GNUstep-make était en 64 bits.
Il se trouve que GNUstep ne se comporte pas comme d'autres logiciels que je connais. Honnêtement, GNUstep et moi, c'est... À la base, je voulais juste tester Darling sur ArchLinux. On ne va pas réinventer la roue ; si je suis arrivé à ce résultat, c'est qu'il n'y a que comme ça que ça marche. Et j'ai fait ça uniquement dans le but de virer les paquets
lib32-gnustep-clang-svn, qui sont, pour rappel, entièrement en 32 bits et installés dans le /opt (donc une horreur). À l'inverse,
gnustep-multilib-clang-svn s'installe uniquement dans le /usr/, et des fichiers sont communs aux versions 32 et 64 bits (car génériques en quelque sorte). Au fond, ce paquet n'est que la somme de la version 64 bits, avec des bibliothèques 32 bits et quelques fichiers qui permettent de fournir les bibliothèques 32 bits.
Je vous remercie de votre aide, et je sais que GNUstep demande un gros effort de compréhension pour avoir une version 64 bits avec, en plus, au moins les bibliothèques 32 bits. Peut-être qu'on ne peut comprendre que lorsqu'on a testé, c'est vrai qu'au premier coup d’œil, on peut se dire que j'ai rien compris aux paquets, mais je vous assure que je n'arrive pas à compiler fournir des bibliothèques 32 bits sans toute la suite logicielle "en 32 bits". Et vu que je ne vous souhaite pas de vous pencher en profondeur sur ce cas (car on perd vite beaucoup de temps, il ne faut pas oublier que ça fait au moins 5 paquets sur lesquels ils faut se concentrer) car j'estime que j'ai déjà moi-même passé trop de temps dessus. Je pense qu'il est plus raisonnable de garder ce résultat, car ça fonctionne, et je doute sincèrement qu'on puisse l'améliorer pour parvenir au résultat dont tu parlais (c'est-à-dire des paquets lib32- qui fournissent uniquement des bibliothèques et en 32 bits uniquement). Je ne sais pas si ça en vaut tellement la peine de se casser encore la tête à ce sujet, LubosD n'a pas fait de commit depuis plus d'un mois...