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

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

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

Message par Xorg »

Salut.

Vous connaissez peut-être Wine (Wine Is Not an Emulator), qui permet d'exécuter des applications compilées pour Windows (binairement parlant, elles portent le doux nom de PE32 executable, pour les applications 32 bits) sous GNU/Linux, BSD, Solaris et (Mac) OS X.
Il y a peu de temps, j'ai trouvé un autre projet, qui a aussi la vocation d'exécuter certaines applications non-compilées pour GNU/Linux sous GNU/Linux. Elle permet plus exactement d'exécuter les binaires Mach-O executable sous GNU/Linux, pour simplifier, les programmes pour Darwin et OS X (note : c'est depuis la version 10.8 que le préfixe 'Mac' a officiellement disparu). Car je l'avoue, il y a encore peu de temps de ça, je me demandais encore pourquoi, alors qu'OS X est de la famille des UNIX, et GNU/Linux un UNIX-like, et par la même occasion tous les deux compatibles POSIX, pourquoi ils n'étaient pas compatibles au niveau binaire... J'ai donné la réponse plus haut; le noyau Linux supporte officiellement les binaires ELF.
J'ai été surpris quand j'avais lu en décembre, sur Phoronix, qu'un projet de ce type venait "seulement" de naître. J'avais gardé ça de côté, et il y a peu, je me suis mis le défis de faire tourner Darling sous ArchLinux. Et c'est là qu'ont débuté les choses marrantes... :mrgreen:

Darling a nécessité de recompiler le cœur de GNUstep avec Clang. Certes, ça ne fait "que" six paquets de plus, mais pourquoi pas. Après de nombreuses bêta-tests en interne, qui m'ont demandé une forte sollicitation de VirtualBox pour éviter les gros problèmes sur mon système (la preuve en image, j'ai enfin réussis à proposer, à peu près proprement, GNUStep compilé avec Clang. C'est seulement à partir de ce moment là que j'ai pu vraiment proposer Darling à la communauté.
Trêve de bavardage, voici le paquet sur AUR, qui puise ses sources sur le git du projet Darling : darling-git

Dans le PKGBUILD, je propose alternativement le fork de Crwulff, qui est à mes yeux un Darling amélioré (il reprend le Darling original de LubosD, les nouveaux commits de Darling, mais il y a des patchs supplémentaires).
J'ai aussi un problème avec gnustep-libobjc2-clang-git, qui veut créer une bibliothèque /usr/lib/libobjc.so, mais une du même nom existe déjà car elle appartient à gcc-libs. Bien que libobjc.so de gnustep-libobjc2-clang-git se vente de pouvoir remplacer la libobjc.so de gcc-libs, je n'ai pas trouvé de moyen de faire cohabiter ces deux bibliothèques, sans causer un quelconque conflit. Donc pour l'instant, mis à part supprimer/renommer /usr/lib/libobjc.so avant l'installation de gnustep-libobjc2-clang-git, ou bien utiliser l'option --force dans pacman, je n'ai pas trouvé de solution à ce problème. J'ai fouillé dans les sources de GNUstep Objective-C, sans succès.
De plus, il y a un problème avec le fichier /usr/include/unistd.h lors de la compilation de Darling. J'ai lu que c'était "normal", car il y a un conflit de nom de variables dans ce fichier il me semble (la faute des développeurs de glibc qui ne veulent pas patcher d'après ce que j'ai compris), donc je propose interactivement de corriger ce soucis dans darling-git, en espérant que ça ne soit pas trop déprécié comme méthode.

Bien sûr, ce n'est pas encore grâce à ça que vous pourrez faire tourner, par exemple, les gros jeux OpenGL compilés pour OS X, vu qu'il manque beaucoup de Frameworks, mais je cherche une solution à ça, tout comme les développeurs du projet (j'avais réussis à ajouter le framework QuickTime dans mes essais, c'était déjà un bon début).

Si j'ai écris ce message, c'était pour vous faire connaître ce projet, si vous ne le connaissiez pas. Je pense qu'il a le potentiel de devenir autant intéressant que Wine, même s'il n'est pas très populaire et pas très développé actuellement.

Bien entendu, je reste ouvert à toutes propositions, suggestions, remarques, et cetera.

Merci de m'avoir lu, bonne journée. :)
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

Xorg a écrit :J'ai aussi un problème avec gnustep-libobjc2-clang-git, qui veut créer une bibliothèque /usr/lib/libobjc.so, mais une du même nom existe déjà car elle appartient à gcc-libs. Bien que libobjc.so de gnustep-libobjc2-clang-git se vente de pouvoir remplacer la libobjc.so de gcc-libs, je n'ai pas trouvé de moyen de faire cohabiter ces deux bibliothèques, sans causer un quelconque conflit. Donc pour l'instant, mis à part supprimer/renommer /usr/lib/libobjc.so avant l'installation de gnustep-libobjc2-clang-git, ou bien utiliser l'option --force dans pacman, je n'ai pas trouvé de solution à ce problème. J'ai fouillé dans les sources de GNUstep Objective-C, sans succès.
Et c'est comme ça qu'on casse la base de données de pacman. :sm:
Comme solution, tu as:
-compiler statiquement ton application (ainsi libobjc sera inclu dans l'exécutable -- inconvénient: plus lourd) ;
-conserver en dynamique et donc modifier le répertoire d'installation des bibliothèques (ainsi le make install te placera ton libobjc.so dans /usr/share/ton_paquet ou /opt/ton_paquet par exemple). Ensuite tu rajoutes un fichier bash qui te fait un export LD_LIBRARY_PATH avec ce chemin et qui te lance l'application (script que tu places dans /usr/bin à la place de l'autre que tu peux placer aussi dans usr/share). Ainsi à l'exécution la liaison se fera d'abord avec les versions de ce répertoire avant de compléter avec le reste. Cette méthode est longue à décrire, mais elle est couramment utilisée et très simple à mettre en œuvre (si tu ne trouves pas d'exemple, je dois avoir un paquet au moins dans ce cas). :wink:
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Il m'a fallut un moment pour être sûr de bien comprendre ce que tu as écrit. Oui, sur le plan théorique, ça parait bon. Pour mes tests, j'ai trouvé quelque chose d'intéressant : gnustep-base-clang-git (c'est le paquet qui est compilé après l'installation de gnustep-libobjc2-clang-git, et donc il a besoin de ce dernier par la même occasion pour fonctionner), dans ses sources, contient un fichier configure qui est d'ailleurs sollicité dans la fonction build(). Dans ce fichier, j'ai trouvé que cette fameuse bibliothèque, /usr/lib/libobjc.so, est en faite recherchée sous plusieurs noms différents :

Code : Tout sélectionner

if test -f "$GNUSTEP_LDIR/libobjc.a" -o -f "$GNUSTEP_LDIR/libobjc.so" -o -f "$GNUSTEP_LDIR/libobjc.dll.a" -o -f "$GNUSTEP_LDIR/libobjc-gnu.dylib" -o -f "$GNUSTEP_LDIR/libobjc_gc.a" -o -f "$GNUSTEP_LDIR/libobjc_gc.so" -o -f "$GNUSTEP_LDIR/libobjc_gc.dll.a" -o -f "$GNUSTEP_LDIR/libobjc_gc-gnu.dylib"; then
Après un test (en machine virtuelle, bien entendu, pour éviter de pourrir la BDD de Pacman, ainsi que mon système), j'ai créé les liens symboliques suivants :

Code : Tout sélectionner

lrwxrwxrwx 1 root root     14  2 juil. 21:48 libobjc.a -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:51 libobjc.dll.a -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:51 libobjc_gc.a -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:52 libobjc_gc.dll.a -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:52 libobjc_gc-gnu.dylib -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:51 libobjc_gc.so -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     14  2 juil. 21:51 libobjc-gnu.dylib -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     12  2 juil. 21:55 libobjc.so -> libobjc.so.4*
lrwxrwxrwx 1 root root     16 31 mai   17:16 libobjc.so.4 -> libobjc.so.4.0.0*
-rwxr-xr-x 1 root root 106600 31 mai   17:16 libobjc.so.4.0.0*
-rwxr-xr-x 1 root root 199724  2 juil. 21:31 libobjc.so.4.6*
libobjc.so.4.0.0 correspond en réalité à la bibliothèque appartenant à gcc-libs, et libobjc.so.4.6 à gnustep-libobjc2-clang-git.

Il est ressort qu'en oubliant gcc-libs (pas de libobjc.so lui appartenant donc), le paquet gnustep-base-clang-git est construit correctement que grâce aux bibliothèques nommées libobjc.a et libobjc.so (quand elles pointent vers libobjc.so.4.6). En gros, les autres noms de bibliothèque (libobjc.dll.a, libobjc_gc.a...), peu importe la situation, ne fonctionne pas (curieux ça d'ailleurs).
Enfin bref, je n'avais que deux possibilités, et vu que le nom libobjc.so est réservé par gcc-libs, je ne pouvais utiliser que libobjc.a. Pour récapituler, en créant un lien symbologie nommé libobjc.a qui pointe vers libobjc.so.4.6, et sans avoir aucun fichier nommé libobjc.so, ça fonctionne.
Mais, après avoir réinstallé correctement gcc-libs, je me retrouve donc en toute logique avec ceci :

Code : Tout sélectionner

lrwxrwxrwx 1 root root     14  2 juil. 22:21 libobjc.a -> libobjc.so.4.6*
lrwxrwxrwx 1 root root     16 31 mai   17:16 libobjc.so -> libobjc.so.4.0.0*
lrwxrwxrwx 1 root root     16 31 mai   17:16 libobjc.so.4 -> libobjc.so.4.0.0*
-rwxr-xr-x 1 root root 106600 31 mai   17:16 libobjc.so.4.0.0*
-rwxr-xr-x 1 root root 199724  2 juil. 21:31 libobjc.so.4.6*
Donc on peut penser que c'est une bonne façon de contourner le problème, mais non. Dès ce moment là, gnustep-base-clang-git refuse de nouveau de compiler, car je pense que libobjc.so (de gcc-libs) refait conflit.
C'est marrant, j'aurais presque juré que la fonction test donnait le nom libobjc.a prioritaire sur libobjc.so, mais je vois que non.

Donc même si j'arrivais à mettre au point ce dont tu parles, le libobjc.so de gcc-libs viendrait quand même mettre le bordel je pense.
Puis j'ai essayé le export LD_LIBRARY_PATH=/usr/lib/libobjc.so.4.6, mais le résultat n'a pas été convainquant, ça n'a rien changé. :?

En tout cas, merci de t'être creusé la tête pour résoudre mon problème. J'ai réussi dans mes tests à faire en sorte que gnustep-libobjc2-clang-git crée des bibliothèques nommées libobjc2.so et libobjc2.so.4.6 lors du make (en modifiant les Makefiles), mais gnustep-base-clang-git n'a rien voulu savoir. :mrgreen:
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 17187
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

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

Message par benjarobin »

Oula... Je crains que tu ne maitrises pas du tout ce que tu fait... Pour information un .a est une librairie static et un .so est dynamique...
Faire un LD_LIBRARY_PATH=/usr/lib/libobjc.so.4.6 n'a pas vraiment de sens... Désolé mais je n'ai pas trop le temps de rentrer dans les détails (Il se fait tard). Relit posément ce qu'a écrit FoolEcho
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

.a et .so, ce ne sont que des extensions. Dans ce cas là, même si elle s'appelait bien .a, en réalité c'était une .so, et ça marchait pareil. C'était un vieux renommage pour essayer d'éviter ce conflit, j'ai fait comme j'ai pu.
Je pensais que LD_LIBRARY_PATH était un genre de variable d'environnement. En fait, je n'ai pas précisé, mais FoolEcho, tu parles beaucoup de binaires, or il n'y a pas de binaires dans ce paquet.
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
oktoberfest
Maître du Kyudo
Messages : 1855
Inscription : mer. 06 janv. 2010, 13:51
Localisation : Ried - Alsace - France

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

Message par oktoberfest »

dans LD_LIBRARY_PATH tu indiques une liste de répertoires (et non pas une liste de fichiers) dans lesquels le linker va chercher en priorité les librairies nécessaires. Ce qui dit FoolEcho c'est que tu installes ton paquet dans /usr/share/mon_paquet (par exemple) et que si le résultat de l'installation fait que les librairies sont dans /usr/share/mon_paquet/lib, alors tu fais un :

Code : Tout sélectionner

LD_LIBRARY_PATH=/usr/share/mon_paquet/lib
Afin d'utiliser en priorité /usr/share/mon_paquet/lib/libobjc.so par rapport à /usr/lib/libobjc.so.
La majorité des bugs se situe entre la chaise et le clavier...
Arrêtez de vous prendre la tête avec les partitions... passez au LVM
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

Pour détailler un peu mieux ce que je disais (mais n'ayant pas regardé plus précisément ton cas, il te faudra adapter):

1- tu prends le paquet qui te donne libobjc.so, mais au lieu d'installer dans usr/ (conflit avec gcc-libs donc c'est mort) tu l'installes dans usr/share/ton_paquet ou dans opt/ton_paquet. Pour se faire, tu n'as besoin que de modifier le prefix donné au configure (/usr/share/ton_paquet ou /opt/ton_paquet à la place de usr) et reconstruire le paquet.

2- pour ensuite compiler ton paquet contre cette bibliothèque, tu modifies son configure en lui disant de chercher cette lib. À ce niveau normalement, tu dois pouvoir modifier le configure pour pointer vers le répertoire de la lib (-I/usr/share/ton_paquet/include -L/usr/share/ton_paquet/lib/) afin que le configure le trouve (on peut aussi jouer sur PKG_CONFIG_PATH, LDFLAGS).

3- une fois compilé, pour exécuter, il te suffit de créer un lanceur avec export LD_LIBRARY_PATH=/usr/share/ton_paquet/lib (à l'éxecution c'est ce répertoire contenant libobjc.so qui prévaudra avant /usr/lib) ton_exécutable.

Exemples tirés de paquets que je maintiens (ça devrait être plus clair :mrgreen: ):
-libvalhalla (pour le 2). Dans ce PKGBUILD, il s'agit de compiler contre ffmepg-compat et non ffmpeg (marche pô sinon). Or le premier, bien qu'installé est inconnu au bataillon lors du configure, il faut donc jouer sur PKG_CONFIG_PATH et LDFLAGS pour que le configure le reconnaisse.
-autopanogiga (pour le 3, mais tu devras compiler le paquet ou au moins récupérer le source). Ce paquet est précompilé et utilise une version patchée de qt4 et c'est donc ces dernières ainsi que d'autres non présentes dans le système que l'exécutable doit utiliser. Il y a un lanceur dans /usr/bin qui appelle le vrai, opt/autopanogiga/AutopanoGiga.sh qui fait l'opération du LD_LIBRARY et du lancement de l'application.
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Merci énormément pour votre aide, ça m'a beaucoup fait avancer. Du coup je refais le tour intégral du projet là, je n'avais pas remarqué qu'en utilisant mes paquets, Darling fait un crash dump. Je vous dirai plus tard comment j'ai procédé exactement, quand j'aurai fixé ce problème et distribué les nouvelles sources (oui, bêta-test interne actuellement). :)
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Oups, il me semblait que j'avais posté... Alors pour les intéressés, j'ai refais le tour de tout le projet (darling-git et du groupe gnustep-clang-git), j'ai mis depuis déjà quelques jours la deuxième version (bien que je préfère le terme révision) des paquets. En fait, j'ai découvert dans gnustep-make le fichier de configuration /etc/GNUstep/GNUstep.conf, j'ai donc juste déplacé les bibliothèques vers /usr/share/GNUstep/lib, comme tu me l'avais suggéré FoolEcho.
Ensuite, pour les binaires, j'ai aussi fait comme tu m'as dit : j'ai déplacé les binaires vers /usr/share/darling-git, et j'ai créé des scripts exécutables, avec le export LD_LIBRARY_PATH=/usr/share/GNUstep/lib dedans, comme ça.
J'aurais pu créer les scripts et les ajouter et tant que fichier, et cetera, mais au moins ça fait économiser le calcul de sommes de contrôle, on va dire.
Il manque toujours les fameux Framework, je comptais y jeter un oeil. Pour l'instant, la seule feinte, c'est de rediriger ceux manquants vers /dev/null par exemple, mais bien entendu, il y a des fortes chances pour que l'application ne fonctionne pas correctement. Au moins dans cette deuxième révision du paquet, j'ai fixé les "core dumped" que je n'avais pas vu la première fois.

Donc merci énormément à toi FoolEcho pour l'aide, ainsi qu'à Oktoberfest et Benjarobin, ça fait toujours plaisir de voir que les Archers sont des personnes assez douées dans le domaine. :D


Sinon, vous avez sans doute remarqué un petit soucis avec le Projet Darling, c'est que si on peut exécuter les binaires, encore faut-il pouvoir y accéder, car les fichiers .dmg sous GNU/Linux, ça s'ouvre, mais il faut savoir comment s'y prendre quoi, et ça peu prendre un peu de temps comme manipulation.
J'en ai donc profité pour créer un script, que j'ai nommé dmg2dir (en clin d’œil à dmg2img, qui m'a permis de réussir ce que je voulais faire). J'ai mis le lien du dépôt git, c'est sûr, un dépôt pour ce genre de chose, ça n'est vraiment pas indispensable, je sais, mais ça me faisait plaisir.
Il y a même un PKGBUILD sur AUR si vous voulez, j'ai nommé le paquet dmg2dir-git, pour être original.
Vous yeux risquent de saigner si vous regardez le script, donc je préviens, oui, c'est prévu que je fasse mieux.

À ce sujet, je voulais bien entendu ajouter des fonctions, mais d'abord je voulais savoir : si, par exemple, je veux faire un mode bavard (verbose), il faut que j'inclue une variable avec un jeu de conditions comme ceci, ou on peut faire plus simple (j'ai l'impression que ça alourdit le code de toujours tout écrire en double) ?

Code : Tout sélectionner

verbose=1
if [[ $verbose == 1]; then
  cp -v ...
else
  cp ...
fi
Je voulais essayer au final de faire un programme en ligne de commande assez modulaire, j'entends par là qui propose d'utiliser des options (genre -n pour --name, etc...), d'où la nécessité que je fasse des fonctions (je m'en occuperai d'ici peu, ce n'est qu'une question de temps, je sais comment les faire). Vous savez où je peux trouver de la documentation qui explique comment faire ceci ? Je voulais faire ça à l'instar de tous les grands programmes qu'on utilise en ligne de commande, tout bêtement.

Merci d'avance, bonne journée. :)
Dernière modification par FoolEcho le dim. 07 juil. 2013, 12:35, modifié 1 fois.
Raison : manquait un = sur une balise url
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

:D (j'ai eu un peu peur en voyant le pavé... puis son départ: "ça c'est bon, ça aussi, là j'ai fait ce qu'on m'a dit" ... j'ai eu peur du "finalement, ça marche pô" :mrgreen: )
Xorg a écrit :Sinon, vous avez sans doute remarqué un petit soucis avec le Projet Darling, c'est que si on peut exécuter les binaires, encore faut-il pouvoir y accéder, car les fichiers .dmg sous GNU/Linux, ça s'ouvre, mais il faut savoir comment s'y prendre quoi, et ça peu prendre un peu de temps comme manipulation.
Pas regardé en ce qui me concerne ( :cocktail: :atable: ). Je ne fais que de l'expertise technique/conseil de développement. :wink: :humour:
Xorg a écrit :À ce sujet, je voulais bien entendu ajouter des fonctions, mais d'abord je voulais savoir : si, par exemple, je veux faire un mode bavard (verbose), il faut que j'inclue une variable avec un jeu de conditions comme ceci, ou on peut faire plus simple (j'ai l'impression que ça alourdit le code de toujours tout écrire en double) ?
Utilise la syntaxe du switch/case, le shell connaît et c'est nettement plus lisible.
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Heu ouais, faut que j'améliore ça aussi, moins de blabla, et plus directement au but. :mrgreen:

J'ai jeté un œil pour le switch/case dont tu parlais. Au final, le /usr/bin est très parlant, je vois mieux de quoi tu veux parler, et je vois mieux comment arriver à mon but. Merci bien pour ton aide. :)
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Voilà, j'ai amélioré dmg2dir-git. Il me reste encore à faire, mais c'est déjà mieux.
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Je viens apporter quelques nouvelles du projet, car j'ai l'impression que la présence de Darling sur AUR a éveillé la curiosité de certains. :D

Le paquet étant dorénavant en version 5, je ne vais pas cacher que j'ai donc corrigé quelques boulettes (la preuve), par conséquent, je pense qu'on peut qu'on peut l'utiliser avec moins d’appréhension.

J'ai forké le projet original de LubosD, simplement pour essayer d'ajouter le support de nouvelles bibliothèques et frameworks. Bon, j'ai voulu scinder son fichier dylib.conf en deux fichiers, ce qui fait que mon fork peut se retrouver incompatible avec le projet initial, mais ça c'est mon soucis.
J'ai aussi ajouté la liste des paquets qu'il faut installer pour que ça installe les bibliothèques nécessaires, si le besoin s'en fait ressentir ; les noms de paquet correspondent aux paquets des dépôts officiels d'ArchLinux, ainsi que ceux de AUR (sans distinction entre les deux), donc je conseille plutôt d'utiliser yaourt.

Après quelques tests, il est plus au moins possible d'utiliser opencflite-svn pour procurer le framework CoreFoundation, mais il y a un conflit avec gnustep-corebase-clang-git. Toutefois, son utilisation ajoute plus de symboles dans la bibliothèque libCoreFoundation.so, donc je vais voir si c'est intéressant d'essayer de l'implanter dans une version spécifique pour Darling ou pas.
OpenBSM peut fournir libbsm.so (qui m'a l'air beaucoup sollicitée sous OS X) et devrait pouvoir fournir libauditd, mais vu qu'à la base c'est destiné pour OpenBSD, il manque des en-têtes nécessaires à la compilation de ce dernier. Ça pourrait se faire, mais ces licences BSD sont parfois une prise de tête, je crois que je vais laisser tomber.
Je n'ai pas réussis à compiler JGIS (Java Interface for GnuStep) qui devrait fournir le support du framework JavaVM. Mais je doute finalement que le Java au sein de Darling soit vraiment important, car après tout, le Java est un langage cross-plateform grâce à sa machine virtuelle.

Mis à part cela, le petit script dmg2dir a bien mûri. Certes, je pense que certains lui trouveront facilement des défauts, mais l'essentiel reste là, il permet -normalement- d'extraire un fichier .dmg sans nécessité de privilèges, contrairement au programme de LubosD qui n'avait fonctionné que lorsque je m'étais logué en root quand je l'avais essayé.

Je crois que j'ai fait le tour de tout. Peut-être qu'il faudrait que j'envoie un mail à LubosD si mon travail sur les bibliothèques et les frameworks peut lui être utile. :)
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Et quatrième message... :mrgreen:

Pour les adeptes de darling-git qui utilisent ArchLinux 64 bits, peut-être que darling-multilib-git peut vous intéresser.
Oui, utiliser le répertoire /opt pour installer GNUstep 32 bits n'était peut-être pas judidieux, mais j'ai une excuse : ça devenait trop dur de faire cohabiter GNUstep 32 bits à coté de GNUstep 64 bits. :roll:
Peut-être que je suis un lâche, mais j'ai encore les traces de mes PKGBUILDs pour lib32-gnustep-clang-svn qui s'installaient normalement. Le problème, c'est rien que pour lib32-gnustep-make-clang-svn, je me retrouvais à renommer plein de fichiers pour éviter les conflits, ainsi qu'à en modifier pas mal pour prendre en considération les changements. Et puis quand on se plonge dans les PKGBUILDs juste de Darling, on peut se demander où est le principe KISS : j'avoue, rien que pour mettre français et anglais, ça "pollue", au moins visuellement, le paquet.

Mais cela dit, je reste quand même assez "fier" d'avoir réussis à compiler Darling en multilib, car c'est pour moi une première de faire des paquets en 32 bits pour architecture 64 bits (en plus avec LLVM/Clang, c'est encore plus marrant :mrgreen: ), et en plus de ça la documentation officielle de Darling pour le multilib est incomplète.

Prochaine étape le Grand Central Dispatch (GCD) ? :rtfm:
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

Aïe, je t'arrête au vue du contenu des PKGBUILDs: les modifications à la volée d'un autre paquet comme tu fais (le /usr/include/unistd.h de glibc), même avec demande auprès de l'utilisateur sont une horreur absolue (et sous Arch, c'est même pire)! Si tu veux compiler contre autre chose que contre le glibc fourni, il faut installer cette version quelque part et lier ton programme contre.
Xorg a écrit :Oui, utiliser le répertoire /opt pour installer GNUstep 32 bits n'était peut-être pas judidieux, mais j'ai une excuse : ça devenait trop dur de faire cohabiter GNUstep 32 bits à coté de GNUstep 64 bits. :roll:
Pas trop compris tes explications. :?
Et je pense que c'est là que le bât blesse: l'organisation de tout ça et la compilation ne te paraissent pas claires.
Xorg a écrit :Oui, utiliser le répertoire /opt pour installer GNUstep 32 bits n'était peut-être pas judidieux, mais j'ai une excuse : ça devenait trop dur de faire cohabiter GNUstep 32 bits à coté de GNUstep 64 bits. :roll:
Tu peux aussi voir à compiler ton programme statiquement même si ça ne se fait plus trop (c'est-à-dire qu'il fonctionnera en standalone: ça augmente le poids de l'application mais tu t'affranchis des questions de bibliothèques).
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

FoolEcho a écrit :Aïe, je t'arrête au vue du contenu des PKGBUILDs: les modifications à la volée d'un autre paquet comme tu fais (le /usr/include/unistd.h de glibc), même avec demande auprès de l'utilisateur sont une horreur absolue (et sous Arch, c'est même pire)! Si tu veux compiler contre autre chose que contre le glibc fourni, il faut installer cette version quelque part et lier ton programme contre.
Je ne sais pas quoi faire. Je peux juste mettre un warning "Blablabla" à la place du paté, mais j'ai peur que les gens passent leur temps à venir me dire sur AUR "ça ne compile pas". À l'inverse, je ne suis pas certain vouloir maintenir une version de glibc modifiée.
Dans ce cas, est-ce que la meilleur solution serait d'avoir un fichier /usr/include/unistd.h déjà modifié, et ensuite je n'aurais plus qu'à adapter les directives du préprocesseur dans les sources ?
FoolEcho a écrit :Pas trop compris tes explications. :?
Et je pense que c'est là que le bât blesse: l'organisation de tout ça et la compilation ne te paraissent pas claires.
La section "multilib" sur le site du projet est incomplète oui. J'ai compris comment ça fonctionnait en étudiant des PKGBUILDs de paquets lib32-*.
Mais rien ne me dit que je n'ai pas oublié des flags ou des choses comme ça, vu que je ne sais pas si pour compiler GNUstep en 32 bits sur un OS 64 bits il faut des flags spéciaux, par exemple est-ce que j'ai besoin de ASMFLAGS=-m32, ou encore de CFLAGS=-m32, vu que j'ai déjà CC="clang -m32" CXX="clang++ -m32".
Est-ce qu'il existe un moyen de vérifier les dépendances (voir s'il en manque ou s'il y en a trop) ? Namcap m'a l'air pas si fiable que ça.
FoolEcho a écrit :Tu peux aussi voir à compiler ton programme statiquement même si ça ne se fait plus trop (c'est-à-dire qu'il fonctionnera en standalone: ça augmente le poids de l'application mais tu t'affranchis des questions de bibliothèques).
Et justement, d'une part j'ai besoin des bibliothèques partagées pour Darling, donc je ne veux pas de statique. D'autre part, il n'y a pas que les bibliothèques qui posent soucis : il y a les exécutables mais aussi les en-têtes.
En gros, si on prend gnustep-make-clang-svn et qu'on se contente simplement d'ajouter les flags "-m32", ça ne suffit pas. Tout GNUstep repose sur des variables d'emplacement, donc dès qu'on renomme un fichier pour éviter les conflits dans le système de fichier, ça ne marche pas, car du coup GNUstep utilisera par défaut les fichiers issus de la version 64 bits.

Je te donne un exemple concret : cmake va appeler le script /usr/bin/gnustep-config. Mais gnustep-config va chercher la configuration de GNUstep dans le fichier /etc/GNUstep/GNUstep.conf, donc ça fonctionne normalement quand tu n'as qu'une version de GNUstep.
Maintenant, si je veux installer une deuxième version de GNUstep (une en 32 bits), ça va vouloir recréer un /usr/bin/gnustep-config et un /etc/GNUstep/GNUstep.conf, et ça fait conflit.
Quand j'avais eu mon problème avec les libobjc2.so, tu m'avais dit de mettre la nouvelle bibliothèque, qui posait conflit, ailleurs.
Pour en revenir à ma version de GNUstep 32 bits, j'avais d'abord opté pour un renommage des fichiers qui faisaient conflit (/usr/bin/gnustep-config en /usr/bin/gnustep-config32, et cetera...), mais non, ça ne marche pas, car il faut modifier TOUS les autres fichiers manuellement, pour dire à GNUstep 32 bits d'utiliser /usr/bin/gnustep-config32 au lieu de /usr/bin/gnustep-config.
J'ai pris l'exemple que d'un fichier, mais c'est ça, quand tu renommes un fichier, tu te retrouves à devoir appliquer la modification dans tous les autres fichiers. Et vu qu'après, il y a plus d'un fichier à renommer, ça devient un travail pharaonique.
J'ignore si c'est plus clair ou pas. Donc la solution que j'ai retenue, ça a été d'utiliser --prefix=/opt/GNUstep32, comme ça :

Code : Tout sélectionner

── opt
    └── GNUstep32
        ├── bin
        ├── etc
        ├── include
        ├── lib32
         └── share
Au moins, la version 64 bits de GNUstep reste inchangée, et la version 32 bits ignore complètement la version 64 bits.
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

Pas simple de te répondre (n'ayant pas regardé la construction du truc)... :?
Xorg a écrit :Dans ce cas, est-ce que la meilleur solution serait d'avoir un fichier /usr/include/unistd.h déjà modifié, et ensuite je n'aurais plus qu'à adapter les directives du préprocesseur dans les sources ?
:? ... ben... c'est un peu l'idée, oui. Sauf que normalement tu as toutes les variables d'environnement pour faire ça sans tout retravailler...
Xorg a écrit :Est-ce qu'il existe un moyen de vérifier les dépendances (voir s'il en manque ou s'il y en a trop) ? Namcap m'a l'air pas si fiable que ça.
ldd sur ton exécutable est le plus fiable (après correction des erreurs à la compilation évidemment).
Xorg a écrit :Pour en revenir à ma version de GNUstep 32 bits, j'avais d'abord opté pour un renommage des fichiers qui faisaient conflit (/usr/bin/gnustep-config en /usr/bin/gnustep-config32, et cetera...), mais non, ça ne marche pas, car il faut modifier TOUS les autres fichiers manuellement, pour dire à GNUstep 32 bits d'utiliser /usr/bin/gnustep-config32 au lieu de /usr/bin/gnustep-config.
Pige pas trop... /usr/lib32 est fait pour, /opt au pire. Et au besoin tu fixes à l'exécution les bibliothèques à utiliser en passant LD_LIBRARY_PATH.
Je pense que tu ne positionnes pas les variables comme il faut, «c'est tout» (regarde peut-être comment lib32-glibc et gcc-libs-multilib et autres trucs centraux sont construits).
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

FoolEcho a écrit :
Xorg a écrit :Dans ce cas, est-ce que la meilleur solution serait d'avoir un fichier /usr/include/unistd.h déjà modifié, et ensuite je n'aurais plus qu'à adapter les directives du préprocesseur dans les sources ?
:? ... ben... c'est un peu l'idée, oui. Sauf que normalement tu as toutes les variables d'environnement pour faire ça sans tout retravailler...
J'ai cherché, je n'ai pas trouvé de chose à ce sujet. :?
FoolEcho a écrit :
Xorg a écrit :Est-ce qu'il existe un moyen de vérifier les dépendances (voir s'il en manque ou s'il y en a trop) ? Namcap m'a l'air pas si fiable que ça.
ldd sur ton exécutable est le plus fiable (après correction des erreurs à la compilation évidemment).
D'accord, merci beaucoup. :)
FoolEcho a écrit :Pige pas trop... /usr/lib32 est fait pour, /opt au pire. Et au besoin tu fixes à l'exécution les bibliothèques à utiliser en passant LD_LIBRARY_PATH.
Je pense que tu ne positionnes pas les variables comme il faut, «c'est tout» (regarde peut-être comment lib32-glibc et gcc-libs-multilib et autres trucs centraux sont construits).
Dans le PKGBUILD de lib32-glibc, il y a un gros coup de rm -rf ${pkgdir}/{etc,sbin,usr/{bin,sbin,share},var} à la fin. Donc il ne reste que les bibliothèques 32 bits pratiquement, qui sont dans le /usr/lib32, donc il n'a pas de conflit.
Le problème, c'est que GNUstep-make sert à fabriquer les autres composants de GNUstep, donc si je vire les mêmes répertoires, il ne va plus rien me rester. :non:
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
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 »

Xorg a écrit :En gros, si on prend gnustep-make-clang-svn et qu'on se contente simplement d'ajouter les flags "-m32", ça ne suffit pas. Tout GNUstep repose sur des variables d'emplacement, donc dès qu'on renomme un fichier pour éviter les conflits dans le système de fichier, ça ne marche pas, car du coup GNUstep utilisera par défaut les fichiers issus de la version 64 bits.

Je te donne un exemple concret : cmake va appeler le script /usr/bin/gnustep-config. Mais gnustep-config va chercher la configuration de GNUstep dans le fichier /etc/GNUstep/GNUstep.conf, donc ça fonctionne normalement quand tu n'as qu'une version de GNUstep.
Maintenant, si je veux installer une deuxième version de GNUstep (une en 32 bits), ça va vouloir recréer un /usr/bin/gnustep-config et un /etc/GNUstep/GNUstep.conf, et ça fait conflit.
Mmmm... Je ne comprends pas en fait pourquoi tu veux faire cohabiter gnustep en 32 et 64 bits. Vois dans les dépôts: il y a une version pour i686 et une pour x86_64, donc il te suffit de faire pareil... puis tu construis darling avec l'un ou l'autre selon l'architecture, non ? À te relire un peu mieux (et en regardant un peu plus ce que tu as fait côté PKGBUILD), j'ai l'impression que tu t'es embrouillé: le build proposé sur le site de darling est pour faire la compilation croisée sur un système 64 bits, c'est tout (donc ça n'a d'intérêt que si tu as à fournir les paquets compilés, mais tu n'as pas besoin de ça pour AUR).
«The following statement is not true. The previous statement is true.» :nage:
Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1933
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.

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

Message par Xorg »

Je crois qu'on ne s'est vraiment pas compris. Mais je pense connaître la source du pourquoi. :)

Darling, pour être compilé, requiert des dépendances (cf : http://darling.dolezel.info/en/Build#Re ... pendencies).
Certaines dépendances ont besoin d'être compilées avec Clang (GNUstep).
Une fois les dépendances satisfaites, on peut compiler Darling "ordinairement" (cf : http://darling.dolezel.info/en/Build#Ordinary_Build).

Et c'est là où on ne s'est pas compris je pense : si tu utilises une ArchLinux 32 bits, ça va compiler Darling en 32 bits (ça va de soi), vu que j'ai définit l'architecture comme 'any' dans tous les PKGBUILDs concernant Darling. Et donc, si tu utilises une ArchLinux 64 bits, ça sera Darling en 64 bits, jusqu'à là je pense que tu es d'accord avec moi.
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.

Bref, quand j'ai dit «mais l'inverse est normalement possible», ça sous-entend qu'il existe des exceptions, et Darling 64 bits en est la preuve, vu qu'elle n'est pas capable d'exécuter les binaires types Mach-O qui sont en 32 bits !
La preuve (avec la version VLC pour OS X uniquement en 32 bits, et Darling compilé en 64 bits) :

Code : Tout sélectionner

$ dyld VLC32/VLC.app/Contents/MacOS/VLC
dyld: Cannot execute binary file: This version of Darling dyld cannot load binaries for i386.
Et voilà l'intérêt de la section qui parle d'une construction "multilib" (cf : http://darling.dolezel.info/en/Build#Multilib_Build) : la version "multilib" de Darling permet aussi bien d'exécuter les Mach-O 64-bit que les Mach-O i386.
Je le prouve concrètement (avec la même version de VLC, mais Darling compilé en "multilib") :

Code : Tout sélectionner

$ DYLD_PRINT_LIBRARIES=1 dyld32 VLC32/VLC.app/Contents/MacOS/VLC
dyld: Loaded /usr/lib32/darling/libSystem.so
dyld: Loaded /usr/lib32/libc-2.18.so
dyld: Loaded /usr/lib32/darling/libCoreFoundation.so
dyld: Loaded /usr/lib32/libgcc_s.so.1
Ça n'a rien à voir avec du cross-plateform. :)
Mais pour que dyld32 puisse fonctionner correctement, il lui faut des bibliothèques 32 bits, d'où la création des lib32-gnustep.
Mon problème se trouve justement avec ces lib32-gnustep, et le seul moyen que j'ai trouvé pour contourner le problème a été d'installer la version 32 bits de GNUstep non pas dans le /usr (comme on le fait pour une majorité des paquets), mais dans le /opt. Mais je pense qu'il y a moyen d'y installer dans le /usr, enfin pour cela il faut régler beaucoup de conflits, je travail dessus actuellement.
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.
J'ai, localement, les PKGBUILDs qui permettraient peut-être d'installer GNUstep en 32 bits dans le /usr en plus de GNUstep 64 bits (lui aussi dans le /usr). Bien que j'ai réussis à trouver une solution pour GNUstep-make et GNUstep-libobjc2, il s'avère que GNUstep-base n'en fait qu'à sa tête, alors que je source le bon fichier dans le /etc/profile.d. En effet, il a l'air d'utiliser la configuration de GNUstep 64 bits, alors que toutes les variables font en sorte qu'il utilise celle de la version 32 bits. Je le sais car la FHS de la version 64 bits, et la version 32 bits utilise une FHS totalement différente.
Le pire là-dedans, c'est que GNUstep-libobjc2 lui respecte la FHS correctement (et donc j'utilise la même méthode de compilation pour GNUstep-base), mais lui ne veut rien savoir. Quand le fichier configure est lancé, les variables qui défilent sont les bonnes...


Pour les personnes qui n'ont pas envie de compiler N paquets, j'ai ouvert un dépôt ici : https://github.com/X0rg/Arch-PKGs/wiki/ ... repository
Il faut dire qu'une seule commande, et en plus d'une simplicité, pour ouvrir un dépôt, pourquoi s'en priver... :)
Arch Linux x86_64 - Sway
AMD Ryzen 5 3600X - 32 Go de DDR4 - SSD NVMe 1 To + SSD SATA 250 Go - Sapphire NITRO+ Radeon RX 580
Image AUR___Image Wiki___Image GitHub
Répondre