[AUR] Darling : couche d'émulation Darwin/OSX pour GNU/Linux

Autres projets et contributions
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10504
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » jeu. 29 août 2013, 09:07

Oui, c'est comme pour wine multilib.

Et donc je ne vois pas le souci. :|
Xorg a écrit :En gros, le problème ne résulte pas du fait qu'il est difficile d'installer GNUstep 32 bits ou bien GNUstep 64 bits, mais le problème est d'installer les deux (conflits de fichiers), pour satisfaire pleinement Darling-multilib.
Quels fichiers sont en conflits vu que tu peux choisir où les installer (/usr/lib32, /opt, /usr/share/GNUstep , /usr/share/GNUstep32 par exemple, etc.) ?
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » ven. 30 août 2013, 21:32

Merci FoolEcho pour le mal que tu te donnes à essayer de me comprendre. :mrgreen:

Je récapitule la situation vite fait :
- D'un côté il y a darling-git (qui peut exécuter des Mach-O i386 avec Arch i686 OU BIEN des Mach-O x86_64 avec Arch x86_64) avec : Pas de problème à signaler, je n'ai pas de changements majeurs à effectuer en vue.

- D'un autre côté, il y a darling--multilib-git (qui peut exécuter des Mach-O i386 ET des Mach-O x86_64 avec Arch x86_64 UNIQUEMENT) avec : Pas de problèmes à signaler avec les paquets que j'ai mis sur AUR (sinon ils n'y seraient pas).
De manière général, GNUstep utilise les répertoires :
/etc/{GNUstep,profile.d}/
/usr/bin/
/usr/share/GNUstep/
/usr/include/{objc,Foundation,GNUstepBase,gnustep,GNUstepGUI,AppKit,CoreFoundation}/
/usr/lib/GNUstep/
Ce qui montre que, bien le préfixe lib32-, on est loin d'avoir uniquement des bibliothèques. Ce qu'il se passe, c'est que ça coince si on installe une version de GNUstep compilée en 32 bits en plus de la version compilée en 64 bits, car mis à part le dossier des bibliothèques qui ne sera pas /usr/lib mais /usr/lib32, tous les autres dossiers sont inchangés par défaut. Enfin bref, c'est pour cela que j'ai choisis de simplement installer la version 32 bits de GNUstep dans le répertoire /opt/GNUstep32, mais mon problème, c'est que le dossier /opt n'est pas conçu dans ce but (si on en croit la FHS officielle, il ne sert que pour ce qui est optionnel, «non inclus dans la distribution, installé manuellement»).
C'est pour cela que je travail sur le moyens d'installer proprement GNustep 32 bits dans le /usr, en cohabitation avec GNUstep 64 bits. J'en ai réussis déjà 2/5, mais à 3/5 ça bloque quelque part.
Je vais reprendre ce travail depuis zéro je pense, puis si je ne trouve pas, je partagerai le code qui me pose soucis.

Bonne soirée. :)
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

benjarobin
Maître du Kyudo
Messages : 15396
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par benjarobin » ven. 30 août 2013, 21:39

Bonjour,
Je ne sais pas si je suis HS, mais voilà une petite remarque :
Les paquets multi lib sont conçus pour faire tourner les programmes 32 bits n'existant pas en 64 bits.
Ce qui en découle, est que les paquets multi libs ne doivent contenir que des bibliothèques (des libs) d'où le nom de multi-libs
Les paquets multi libs ne doivent pas contenir d’exécutable ! Donc il ne peut pas y avoir de conflit
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » sam. 31 août 2013, 00:26

Bon, c'est que je me suis planté sur tout le long de la ligne alors. Je comprends un peu mieux pourquoi FoolEcho parlait de cross-plateform.

Prenons le cas à l'envers alors : j'ai Darling-multilib. Comment je fais pour satisfaire les dépendances 32 bits ? Car la version multilib est à 50% (à peu près) un programme 32 bits et à 50% un programme 64 bits. Donc je pense que tu es d'accord avec moi que je suis sensé avoir les bibliothèques utilisées par Darling-multilib autant en 64 bits qu'en 32 bits.
Mais alors comment faire pour récupérer les bibliothèques 32 bits de GNUstep ? C'est donc là mon problème.
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

benjarobin
Maître du Kyudo
Messages : 15396
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par benjarobin » sam. 31 août 2013, 09:37

Je ne suis pas sûr de comprendre, mais normalement un paquet Darling-multilib ne doit contenir que du code 32 bits. Il ne devrait pas contenir de code en 64 bits car ce dernier doit / devrait être fournit par un autre paquet. Après bien sûr tu peux avoir une ou deux exceptions... Donc si le makefile installe trop de chose, c'est à toi à trier pour ne garder que le nécessaire (Je sais c'est un travail assez long...)
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » sam. 31 août 2013, 11:00

J'ai aveuglément suivis les instructions de compilation sur le site de Darling, et voilà où ça me mène.
J'ai tout faux sur toute la ligne avec mon projet "multilib" alors, car mes paquets lib32- ne devraient contenir que des bibliothèques or ce n'est pas le cas, et en plus tu me dis que Darling-multilib ne devrait pas contenir du 32 et 64 bits.
Alors prenons le cas le plus "proche" qui peut m'aider : wine. Wine contient aussi bien des binaires en 32 et 64 bits, que des bibliothèques en 32 et 64 bits. Dans ce cas, le problème viendrait-il du nom que j'ai attribué au paquet multilib (darling-multilib-git) ? Est-ce que tu veux dire que j'aurais du le faire "à la Wine", c'est à dire mettre un if [[ $CARCH == x86_64 ]]; then ... dans le PKGBUILD de darling-git pour que ça construise le version 64 bits que si c'est une Arch Linux 64 bits ?
C'est vrai que je viens de regarder, et les paquets avec le suffixe -multilib ont l'air de contenir uniquement du code 64 bits.
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

benjarobin
Maître du Kyudo
Messages : 15396
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par benjarobin » sam. 31 août 2013, 11:05

Tu mélanges architecture et code 32bits / 64 bits...
Un linux 32 bits (i686) ne peut lancer que des programmes 32 bits, mais il peut tourner sur un processeur i686 comme x86_64, (tous les processeurs récents x86 sont 64 bits)
Un linux 64 bits (x86_64) peut lancer des programmes 64 bits mais aussi 32 bits via les multilib, et il peut uniquement tourner sur un processeur x86_64

Donc un paquet multilib est uniquement pour l’architecture x86_64, mais le code le contenant est majoritairement du 32 bits !
Xorg a écrit :Darling-multilib ne devrait pas contenir du 32 et 64 bits.
Je n'ai pas dit ceci : J'ai dit que ces paquets devraient contenir uniquement du code 32 bits (le PKGBUILD sera uniquement pour l'architecture x86_64)

Les paquets multilib contenant des lib en 32 bits, ont pour but de faire tourner des programmes compilés en 32 bits. Généralement il y a 2 raisons : Le code est fermé donc on ne peut pas recompiler le programme en 64 bits, ou tout simplement le code n'a pas été conçu pour le 64 bits, et donc le compiler en 64 bits ne produira rien de fonctionnel
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » sam. 31 août 2013, 16:10

benjarobin a écrit :Tu mélanges architecture et code 32bits / 64 bits...
Un linux 32 bits (i686) ne peut lancer que des programmes 32 bits, mais il peut tourner sur un processeur i686 comme x86_64, (tous les processeurs récents x86 sont 64 bits)
Un linux 64 bits (x86_64) peut lancer des programmes 64 bits mais aussi 32 bits via les multilib, et il peut uniquement tourner sur un processeur x86_64
Xorg a écrit :Comme tu le sais, il n'est pas possible d'avoir quoi que ce soit en 64 bits sur du 32 bits, mais l'inverse est normalement possible ; alors mon problème ne concerne que les utilisateurs d'ArchLinux 64 bits.
Est-ce que j'ai dit le contraire ? Qui peut le plus peut le moins (en général). :) Peut-être qu'il y a ambiguïté quelque part (car tu remarqueras que la discussion tourne en rond pour savoir comment est-ce qu'il faut procéder pour avoir un Darling compilé en 64 bits mais qui supporte les Mach-O 32 bits).
Ne t'inquiète pas pour moi, j'ai compris depuis bien longtemps la différence entre le 32 et le 64 bits, bien avant de connaître ArchLinux. On aurait même pu mettre sur le tapis les différences entre l'AMD64 et l'Intel64 (anciennement EM64T), ou encore parler de l'ABI x32, mais ça n'a pas d'intérêt ici.
benjarobin a écrit :Donc un paquet multilib est uniquement pour l’architecture x86_64, mais le code le contenant est majoritairement du 32 bits !
Majoritairement ?
cd / && file `pacman -Ql {binutils,gcc-libs,gcc}-multilib | cut -d / -f 2-` | grep 32-bit -> 10 fichiers
cd / && file `pacman -Ql {binutils,gcc-libs,gcc}-multilib | cut -d / -f 2-` | grep 64-bit -> 63 fichiers
Je sais que tu es un expert donc je ne remets pas en doute ce que tu dis, mais quand je vois ça, ça m'étonne un peu du coup.
benjarobin a écrit :Je n'ai pas dit ceci : J'ai dit que ces paquets devraient contenir uniquement du code 32 bits (le PKGBUILD sera uniquement pour l'architecture x86_64)
Donc toi tu dis que dans Darling-multilib-git, je dois juste virer la partie 64 bits (et donc ne pas mettre Darling-multilib-git en conflit avec Darling-git). Oui, c'est largement jouable ça, et facilement. :)
benjarobin a écrit :Les paquets multilib contenant des lib en 32 bits, ont pour but de faire tourner des programmes compilés en 32 bits.
Oui, le but recherché est de pouvoir exécuter les Mach-O i386 (sur Arch Linux x86_64).

Mais ça ne résout toujours pas le soucis de GNUstep ! Si on récapitule, on ne touche pas à darling-git, et darling-multilib-git serait un paquet pour Arch Linux x86_64 qui permettrait d'exécuter des Mach-O 32 bits. Donc avec darling-multilib-git, les Mach-O 32 bits auront besoin de bibliothèques 32 bits pour fonctionner car «on ne peut pas recompiler le programme en 64 bits». Et on retombe dans le même problème, comment créer les bibliothèques 32 bits de GNUstep ? Vu que le groupe lib32-gnustep-clang-svn, lui, créé tous les composants de GNUstep en 32 bits, je ne vois pas comment isoler les bibliothèques 32 bits. Pourquoi ? Car si je compile GNUstep-libobjc2 avec les flags -m32, ça ne marchera pas vu qu'il a besoin d'un GNUstep-make, compilé 32 bits, pour pouvoir fonctionner correctement.
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

benjarobin
Maître du Kyudo
Messages : 15396
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par benjarobin » sam. 31 août 2013, 16:35

Xorg a écrit :Je sais que tu es un expert donc je ne remets pas en doute ce que tu dis, mais quand je vois ça, ça m'étonne un peu du coup.
Tu as raison sur ce point, c'est pour cela que j’utilisait le mot majoritairement. Tu as juste sélectionné les paquets qui font partis des exceptions. :lol:
Si la chaine de compilation en 64 bits ne peut pas produire du 32 bits, car par exemple dans le .configure on a enlevé cette possibilité, alors il est nécessaire de fournir un autre paquet qui sera en conflit avec ce premier.

Tu noteras que gcc ne peut pas compiler en 32 bits, et uniquement en 64 bits, mais gcc-multilib peut faire les 2. Donc si tu arrives à produire un exécutable qui produit du 32 bits et 64 bits comme gcc-multilib, alors ton paquet multilib sera en conflit avec son équivalent non multilib. Par contre si tu ne peux pas, il te faudra faire le paquet multilib sans conflit, et donc il faudra installer la chaine de compilation ailleurs...
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » sam. 31 août 2013, 18:07

benjarobin a écrit :Si la chaine de compilation en 64 bits ne peut pas produire du 32 bits, car par exemple dans le .configure on a enlevé cette possibilité, alors il est nécessaire de fournir un autre paquet qui sera en conflit avec ce premier.
Oui, pas défaut, le groupe lib32-gnustep-clang-svn est en conflit avec le groupe gnustep-clang-svn. C'est pour cela que pour éviter le conflit, j'ai installé le groupe lib32-gnustep-clang-svn non pas dans le /usr (avec le groupe gnustep-clang-svn) mais entièrement dans le /opt.
benjarobin a écrit :Tu noteras que gcc ne peut pas compiler en 32 bits, et uniquement en 64 bits
Tout comme darling-git, qui ne peut pas exécuter du 32 bits mais uniquement du 64 bits (vu que tu prends le cas d'une Arch x86_64). Donc ça veut dire que ce que j'ai fait est OK.
Mais tu veux aussi dire que c'est normal que GNUstep-make 64 bits ne puisse pas compiler le reste de sa famille (libobjc2, base, gui, corebase) en 32 bits, si je comprends bien.
benjarobin a écrit :mais gcc-multilib peut faire les 2.
Tout comme darling-multilib-git, qui exécute aussi bien le 32 bits que le 64 bits. Donc ça veut dire que ce que j'ai fait est OK.
Donc il me faudrait un genre de gnustep-make-multilib ?
benjarobin a écrit :Donc si tu arrives à produire un exécutable qui produit du 32 bits et 64 bits comme gcc-multilib
Soit darling-multilib-git dans mon cas.
benjarobin a écrit :alors ton paquet multilib sera en conflit avec son équivalent non multilib.
C'est le cas. Il n'est pas possible d'installer darling-multilib-git en plus de darling-git, tout comme il n'est pas possible d'installer gcc-multilib en plus de gcc. Les paquets -multilib remplacent le paquet du même nom mais en non-multilib.
Donc si je comprends ta logique, je dois :
- Forker le groupe gnustep-clang-svn en un groupe gnustep-multilib-clang-svn.
- Merger la "partie 32 bits", issue de lib32-gnustep-clang-svn, dans gnustep-multilib-clang-svn.
- Mettre gnustep-multilib-clang-svn en conflit avec gnustep-clang-svn.
- Supprimer lib32-gnustep-clang-svn.
- Modifier darling-multilib-git pour qu'il dorénavant de gnustep-multilib-clang-svn et non de lib32-gnustep-clang-svn.
Ça me parait faisable, il faut que j'essaie alors. Effectivement, je n'avais pas vu les choses sous cet angle lorsque j'ai créé darling-multilib-git.

Merci beaucoup. :D
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

benjarobin
Maître du Kyudo
Messages : 15396
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par benjarobin » sam. 31 août 2013, 19:06

Tes conclusions me semblent corrects, mais attention tout ce que j'ai dis est purement théorique, je ne sais pas comment cela s'applique à ton cas (Je n'ai pas eu le courage / temps de regarder comment tout ceci est fait).
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 13 oct. 2013, 01:27

Bon, je crois avoir enfin palier un de mes problèmes de compilation (à cause de mon PKGBUILD et d'un composant un peu bugué, il faut l'avouer).

Actuellement, le schéma de fabrication de tous mes paquets dits multilib est celui-ci :
- pkgver()
- prepare()
- build() -> ça compile une version 32 bits
- package() -> ça installe la version 32 bits
- build64() -> ça recompile, mais en 64 bits
- package() -> ça installe la version 64 bits

Donc en gros, j'ai créé une fonction non-standard build64() qui est appelée dans la fonction package(). Mais je ne vois pas d'autres alternatives car avec make, si on recompile directement sans installer, on perd bien entendu les fichiers précédemment compilés, vu qu'à ma connaissance, make ne permet pas de choisir où mettre les constructions, contrairement à cmake.

D'où ma question : est-ce que j'ai vraiment le droit de relancer une nouvelle compilation à partir de la fonction package() ? C'est le seul moyen que j'ai trouvé pour mettre binaires et bibliothèques en 32 et 64 bits, au sein d'un même paquet, le tout installé dans le /usr.
Du coup, si j'ai le droit, alors comment nommer les paquets concernés : le suffixe -multilib est-il correct, ou je dois utiliser autre chose ?

Merci d'avance.
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10504
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » dim. 13 oct. 2013, 09:42

Xorg a écrit :D'où ma question : est-ce que j'ai vraiment le droit de relancer une nouvelle compilation à partir de la fonction package() ? C'est le seul moyen que j'ai trouvé pour mettre binaires et bibliothèques en 32 et 64 bits, au sein d'un même paquet, le tout installé dans le /usr.
Un PKGBUILD accepte toute syntaxe bash donc techniquement oui, tu peux (sauf qu'il faut renommer build64() en _build64() pour respecter les standards). Sauf que ce n'est pas à toi de forcer l'enchaînement prepare -> build (ça posera des soucis en plus pour certaines utilisations de makepkg en standalone), donc... non, mauvaise idée. :copain:

Ça fait un petit moment, donc c'est délicat de parler dans le vide. Le mieux serait peut-être que tu nous montres ce à quoi tu es arrivé. :chinois:

Mmmm... Mais sinon, je pense que tu te mélanges. Si l'idée du multilib paraît coller à ton travail, note que tu auras deux PKGBUILDs (c'est le plus propre et le plus simple a priori):
-l'un dédié à l'architecture 32 bits.
-l'autre, ton multilib (donc dédié à x86_64) qui fera donc tourner ton application en 32 et 64 bits (ou qui fournit les deux versions mais pour x86_64 quand même -- j'ai pas bien compris ton histoire et la flemme d'éplucher de nouveau :oops: ).
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 13 oct. 2013, 19:19

Je n'ai en aucun cas forcé l’enchaînement prepare -> build. Non, je m’inquiétais juste à l’ajout d'une fonction non-standard appelée lors de la fonction package, mais vu que tu as l'air de dire que c'est bon (je sais que ça marche syntaxiquement), alors c'est bon pour moi. Je ne voulais pas que quand quelqu'un regarde mon PKGBUILD qu'il se dise que c'était n'importe quoi...

Donc le nouveau groupe (gnustep-multilib-clang-svn) est sur AUR, on peut le trouver ici multilib-clang-svn ou .
Bien entendu, il est accompagné par une nouvelle version de darling-multilib-git adaptée pour, qu'on peut aussi retrouver ici.

Voilà, en espérant que tout soit bon cette fois ! Merci de votre patience et de votre aide. :chinois:

PS : J'ai "simplifié" ces PKGBUILDs (plus de texte en français et en anglais, j'ai gardé uniquement l'anglais), ce qui est un peu mieux lisible au final, donc le reste des paquets devrait bientôt suivre la marche. :wink:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10504
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » dim. 13 oct. 2013, 19:55

Xorg a écrit :Je n'ai en aucun cas forcé l’enchaînement prepare -> build.
Pour avoir jeté un œil :wink: en tous cas, tu fais une partie du build dans le prepare: ce n'est pas sa place ! :shock:

C'est un sac de nœud cette histoire... je ne comprends vraiment pas cette histoire des deux make... :| (sachant qu'il n'en est pas fait mention: http://wiki.gnustep.org/index.php/Build ... with_Clang ; du reste la version sans clang est simple elle aussi: https://projects.archlinux.org/svntogit ... ustep-make :? )
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » dim. 13 oct. 2013, 20:56

FoolEcho a écrit :
Xorg a écrit :Je n'ai en aucun cas forcé l’enchaînement prepare -> build.
Pour avoir jeté un œil :wink: en tous cas, tu fais une partie du build dans le prepare: ce n'est pas sa place ! :shock:
Ah, où ça ? :shock:
FoolEcho a écrit :C'est un sac de nœud cette histoire... je ne comprends vraiment pas cette histoire des deux make... :|
Je crois qu'on va laisser tomber cette histoire, au pire.
Les deux make, c'est, comme tu l'as dit :
FoolEcho a écrit :-l'autre, ton multilib (donc dédié à x86_64) qui fera donc tourner ton application en 32 et 64 bits (ou qui fournit les deux versions mais pour x86_64 quand même).
Donc ces paquets multilib font d'abord une version en 32 bits, puis une version en 64 bits, et le tout est mis au cœur du même paquet. Par exemple, le but surtout recherché est d'avoir des bibliothèques 32 bits (ELF 32-bit LSB shared object) et 64 bits (ELF 64-bit LSB shared object) au sein du même paquet. Car, au final, il faut que Darling-multilib ait autant de bibliothèques 32 que de bibliothèques 64 bits pour fonctionner comme voulu. :)

Mais là, comme je viens de faire, ça fait ce que je voulais faire, donc ça me convient.
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10504
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » lun. 14 oct. 2013, 09:48

Je me suis trompé, j'ai parlé du prepare, mais tu le fais dans le package ce qui revient au même, ça ne va pas (dans le PKGBUILD de gnustep-make-multilib-clang-svn tu appelles build64 dans le package).
Xorg a écrit :Donc ces paquets multilib font d'abord une version en 32 bits, puis une version en 64 bits, et le tout est mis au cœur du même paquet. Par exemple, le but surtout recherché est d'avoir des bibliothèques 32 bits (ELF 32-bit LSB shared object) et 64 bits (ELF 64-bit LSB shared object) au sein du même paquet. Car, au final, il faut que Darling-multilib ait autant de bibliothèques 32 que de bibliothèques 64 bits pour fonctionner comme voulu. :)

Mais là, comme je viens de faire, ça fait ce que je voulais faire, donc ça me convient.
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 :? )

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). :?
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » lun. 14 oct. 2013, 21:05

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 :? )
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). :?
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...
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10504
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par FoolEcho » mar. 15 oct. 2013, 10:47

Xorg a écrit :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.
Oui, bien sûr... Mais tu ne peux pas le faire comme tu le fais, ça ne respecte pas les standards d'Arch (tu fais un build dans package).
Mais tu peux le résoudre simplement en ayant une copie de travail supplémentaire à côté de celle de base: 8)
  • dans prepare(), tu fais une copie de ton répertoire svn qui sera dédié au 64 bits par exemple, et l'original pour le 32
  • dans build() puis package() tu peux faire tes deux make/make install selon le répertoire de travail.
(je n'en ai pas parlé avant parce que... je n'avais vraiment pas compris cette nécessité un brin bizarre 32/64, espérant qu'on puisse découpler ou faire une seule compilation :lol: :pastaper: :merci: )
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [AUR] Darling : couche d'émulation Darwin/OSX pour GNU/L

Message par Xorg » ven. 18 oct. 2013, 23:57

FoolEcho a écrit :Oui, bien sûr... Mais tu ne peux pas le faire comme tu le fais, ça ne respecte pas les standards d'Arch (tu fais un build dans package).
Certes, oui, c'était ma question dans ce message :
Xorg a écrit :une fonction non-standard build64() qui est appelée dans la fonction package()
J'avais compris que tu m'avais dit que j'avais le droit en fait, mais ce n'est pas grave, je sais que je n'ai pas été si clair que ça.

FoolEcho a écrit :Mais tu peux le résoudre simplement en ayant une copie de travail supplémentaire à côté de celle de base: 8)
Ça parait bête, et c'est si simple, mais je n'y avais pas pensé. Effectivement, en 5-10 minutes c'était corrigé, merci beaucoup, mon paquet me parait moins reprochable maintenant. :D

La version 2, donc normalement plus propre, est toujours disponible sur AUR (multilib-clang-svn).
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Répondre