Discussion :

[daerlnaxe]

Rebonjour à tous,

QEMU m'intéresse fortement (j'avoue pas mal pour du rétrogaming mais pas que...), il y a un lot colossal de possibilités, du moins sur linux.

Pour le moment je suis surtout sur la portion Windows10 avec des limitations, et j'aimerai en contourner une car si j'ai bien compris on pourrait émuler une 3DFX sous QEMU, mais surtout si je comprends bien on peut patcher et là ça ouvrirait nombre de possibilités et ça m'intéresse. Pour le moment vu que ça m'arrangerait déjà d'avoir cette possibilité de 3DFX j'aimerai patcher mais je n'ai jamais fait.

Si j'ai bien compris selon la source de ce projet, bien entendu. https://github.com/kjliew/qemu-3dfx, j'ai regardé de ses vidéos et on dirait bien qu'il utiliser une windows host sur certaines pour faire tourner tantôt sur xp, tantôt sur 98 en guest.

Sur ubuntu, car je regardais donc un autre post que j'ai vu passer ici, apparemment on peut faire du passtrough au niveau du GPU qu'on ne peut pas faire sur la version w10 (je crois qu'on peut même pas activer opengl dans les paramètres).

J'ai tenté de suivre les explications mais déjà je ne sais pas si en bout je vais avoir un exe poru windows et en prime j'ai un max de galère pour utiliser MSYS, je suis au dernier point après avoir surmonté tout le reste avant... Le pire c'est que j'avais déjà installé mingw64 enfin bref... à coup de "pacman -S <>" j'ai compris que je devais réinstaller un paquet de choses... J'ai fait "export CC=gcc" et installé gcc par rapport à une erreur (en espérant que ça soit judicieux) et là je cale sur "ERROR: Unrecognized host OS (uname -s reports 'MINGW64_NT-10.0-19044')" au cas où il n'y a pas un autre moyen ? Y'a t'il des gens qui ont déjà recompiqué QEMU ?

Merci d'avance.

[chrtophe]

Sur ubuntu, car je regardais donc un autre post que j'ai vu passer ici, apparemment on peut faire du passtrough au niveau du GPU

Pour faire du passtrough, ton processeur doit gérer le iommu pour Amd ou vt-d pour Intel. le passtrough permet ensuite à un hyperviseur de présenter directement le composant donc ici une carte graphique à une VM sans passer par la couche de virtualisation, le composant étant alors indisponible pour l'hôte.

De ce que j'ai compris, tu fais plutôt de l'émulation,donc pas concerné par le passthrough.

Pour la compilation, en dehors de ton patch, regardes ceci :
https://wiki.qemu.org/Hosts/W32#Nati...lds_with_MSYS2

[daerlnaxe]

Je te remercie, bon j'ai mis " tout" à cette étape


Je vais chercher de la documentation plus tard pour voir à quoi ça correspond, j'ai vu Fortran donc ça je pense que je n'en aurais pas eu besoin.

Je me suis inspiré donc de l'install, je n'ai pas fait la compil de la page pour le moment, j'essaie de relancer la compilation donnée par le site du projet 3dfx

Ca compile ce coup ci, c'est trèèèèèss long, j'espère que c'est allé au bon endroit, pour le moment j'ai du mal à réellement identifier où dans l'arborescence tellement il y a de fichiers, j'espère que ça nettoie après.

Pour le pass trough il m'avait semblé en effet que c'était lié au proc mais aussi à ubuntu j'ai du me tromper ou lire des posts qui dataient, faudra que je regarde de nouveau, mais de toute façon avec mon i7-4470k je ne pourrais pas m'en servir vu qu'il n'est pas compatible apparemment selon cette page

Qu'est ce que je fais, si j'ai d'autres questions j'up avec un nouveau post, je te contacte ou bien j'édite ici ? J'ose pas trop up.

[daerlnaxe]

Bon tant pis j'up... j'espère ne pas me faire gronder.


J'ai bien compilé (gros merci), ça a pris plus d'une heure...

Bon, je ne sais pas pourquoi mais quand je lance via l'explorateur j'ai eu ces erreurs, que je n'ai pas avec la version de base de QEMU
- Il me demande libztd.dll, en fouillant en évitant les deux milliards de pages générées probablement par des bots je vois que c'est un algorithme de compression, je suis allé prendre un pack windows x64 sur github. Ca me fait erreur:

- Je suis allé prendre le pack x86 (win32) et ce coup ci...


J'ai cru que ça avait sauté car ça tournait avec powershell avant de me souvenir que j'avais rentré la variable d'environnement et via CMD je me rends compte que ça ne se lance pas non plus, si quelqu'un a une idée.

Je vais lancer une compilation normale de QEMU juste pour comparer en attendant.

C'est pour ça que je fais une grosse allergie avec ce qu'il faut compiler soi même sur le net, mon maigre taff sur Github est toujours accompagné des dlls (en mentionnant auteurs et pages) ou bien des liens pour aller les prendre. Et en général je préfère ceci dit me passer de nuggets ou dll tiers quand je peux les faire moi même. Là je suis dans un flou total :/

[chrtophe]

C'est pour ça que je fais une grosse allergie avec ce qu'il faut compiler soi même sur le net

c'est vrai que sous Windows, il est rare qu'on compile pour avoir le logiciel.

As-tu respecté à la lettre la procédure fournie sur github ?

Désolé mais j'ai pas le temps de tester moi-même.

[daerlnaxe]

Re,

Déjà tu n'as pas à te justifier, c'est déjà très sympa le temps que tu m'accordes.
Et la compilation est longue, au point que j'ai pu faire pas mal de choses et que j'ai fini par l'oublier (j'étais sur ma recherche pour me requalifier dans l'info, un vrai bordel dont je ne vois vraiment pas de solution par le haut, on te dit qu'on te paie de la formation mais en réalité y'a rien dans le domaine ou presque, et je suis pas chaud chaud sur le peu de formations à distance qu'il y a et ça reste super limité quoiqu'il en soit).

Bref.. oui en effet sur Windows on compile peu, moi ça m'arrive un peu car je cherche souvent des trucs un peu spéciaux qui sont un peu rares à trouver, et du coup je dépoussière aussi régulièrement des trucs obsolètes, mais c'est quand même pas comme ça. J'ai juste des erreurs à corriger, quand je les passe sur le dernier .net core ou .net framework. J'ai des distributions linux mais jusqu'à présent soit j'avais déjà ce qu'il me fallait soit je programmais pour l'avoir (python le plus souvent, ça marche bien). Là c'est vraiment d'un autre niveau et du coup me retrouver avec cet outil là (que j'ai toujours détesté, j'ai chaque fois des problèmes)... Je sais plus quelle librairie je devait utiliser pour un projet c/c++ je suis devenu fou sous windows, une cascade d'installations pour finir sur des bugs... ah si oui, je voulais faire une application p2p pour synchroniser en local, je connaissais pas Resilio ou peut être que ça existait pas encore.

Bon désolé pour le pavé, donc j'ai compilé la version "vanilla" et je retrouve les bugs dessus donc ca va m'orienter vers QEMU.

J'ai pris contact avec le mec qui a fait le projet donc je parle, en réponse il veut une donation de 60$ ce que je comprends bien, tout travail mérite salaire, mais d'une en ce moment je suis plutôt fauché, de deux je paie pas à l'aveugle vu que je ne sais pas si réellement ça va me convenir, et surtout j'aime bien trouver comment faire et non être un assisté. Même si j'ai besoin de conseils parfois, au moins une prochaine fois peut être que je pourrais le faire.

edit:
A tête reposée: je vais regarder ça demain https://stackoverflow.com/questions/...dows-10-64-bit

edit2:
j'ai trouvé ce code dans la faq du repo pour windows, c'est fait par un allemand, c'était tout en bas,je dois aussi tester, vu le temps de compilation ça sera pour demain aussi :/ Je mets tout pour que ça serve et surtout pour pas oublier, si j'arrive à passer le problème je détaillerai pour dire ce qui fonctionne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
    targets="i686-w64-mingw32 x86_64-w64-mingw32"

    for target in $targets; do
      echo Building $target...
      mingw=/usr/$target/sys-root/mingw
      mkdir -p /qemu/bin/ndebug/$target
      cd /qemu/bin/ndebug/$target
      rm -r *
      ../../../configure --cross-prefix=$target-  --disable-guest-agent-msi --disable-werror --extra-cflags="-I $mingw/include" --extra-ldflags="-L $mingw/lib" && make
    done

J'ai l'impression qu'ils compilent tous en cross depuis debian, au pire je verrais si ça passe par ubuntu sinon je vais virtualiser un debian. J'ai jamais testé de faire de cette manière je me demande ce que ça peut donner.

edit3:
en fouilalnt sur autre chose j'ai trouvé cette instruction "pacman -S base-devel cmake gcc zlib" donc ... je tente "$ pacman -S libzstd" et là paf une installation à faire.
Je vais recompiler en priorité là dessus. (Change rien, et je pense que j'avais mal vu, il me semble que c'était déjà installé)

Pourquoi faut il dormir bon sangg !!!

[chrtophe]

Je connaissais pas le Intel Hardware Accelerated Execution Manager qui présente au système une interface compatible KVM, intéressant.

[daerlnaxe]

C'est super puissant comme outil, par contre le maîtriser c'est une autre paire de manche.

Bon un des dev m'a répondu apparemment c'est la bibliothèque Glib (je me demandais) qui ne serait pas à jour.. Petit soucis, je vois pas où la trouver pour le moment. Et je sens que je vais avoir à me taper sa compilation . Faut toujorus que je me foute dans des trucs pas possible, je sens que parti comme c'est parti je vais finir par apprendre carrément à utiliser ça et en ce moment j'ai pas le temps :/. Mais je sens le petit truc en moi qui me dit vas y va voir...

edit:
Bon je tente ça:
"pacman -S mingw-w64-x86_64-glib2" et je recompile

Franchement si je dois dégager un tutoriel de tout ça je sais pas comment je vais faire. Je commence à marquer une partie mais il va y avoir des prérequis à rajouter :/

• Mkdir ~/Qemu-Vanilla && cd ~/Qemu-Vanilla
• git clone https://www.gitlab.com/qemu/qemu
• CD Qemu
• ./configure --enable-gtk --enable-sdl
• make

edit 2:
Point mort complet. Faut que je tente avec Debian, même Ubuntu je suis pas sûr, ça commence bien .. je me lance sur le tuto, il y a des outils que je ne trouve pas dans les paquets :/

[daerlnaxe]

Bon, j'abandonne pour le moment sur windows10, j'ai demandé de l'aide sur ubuntu pour voir si c'était possible de le faire via l'os vu que je virtualise déjà plutôt que d'installer aussi une débian, demandé aussi si le fait de virtualiser n'allait pas me poser de soucis.

Je ne sais pas si je dois faire un nouveau post ou bien poursuivre sur celui-ci. Je pars du tout début en tout cas et je préfère demander ce coup ci qu'expérimenter en piochant des infos à droite et à gauche. Trop de trucs obsolètes je pense.
J'accepte forcément de l'aide aussi ici si ça ne dérange pas.

Donc quand je suis sous Ubuntu ça démarre assez mal. Je me dis que c'est probablement un problème de dépôts mais je préfère demander.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
sudo apt-get install gcc-mingw32 mingw32-binutils mingw32-runtime (pris sur le site de QEMU, correspond à l'installation Debian)
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
sh: 0: getcwd() failed: No such file or directory
E: Impossible de trouver le paquet gcc-mingw32
E: Impossible de trouver le paquet mingw32-binutils
E: Impossible de trouver le paquet mingw32-runtime

[chrtophe]

Essayes d'utiliser directement avec gcc. MinGW étant une adaptation de gcc pour win32. Utile sur Linux uniquement pour faire de la cross-compilation.

[daerlnaxe]

Essayes d'utiliser directement avec gcc. MinGW étant une adaptation de gcc pour win32. Utile sur Linux uniquement pour faire de la cross-compilation.

Mais c'est sur Linux GCC non ? Ou alors tu me dis sous linux justement, mais le projet doit sortir pour Windows en bout donc c'est de la cross-compilation. A moins qu'une version windows existe en dehors de mingw ?

[chrtophe]

Si tu compile pour Windows, oublie ma dernière remarque. Comme tu parlais d'Ubuntu, je pensais que tu comptais utiliser Qemu dessus, pas juste le compiler pour Windows.

[daerlnaxe]

Si tu compile pour Windows, oublie ma dernière remarque. Comme tu parlais d'Ubuntu, je pensais que tu comptais utiliser Qemu dessus, pas juste le compiler pour Windows.

Ah oui, je comprends. Non, le problème reste entier pour le moment, simplement j'essaie de le couper en morceaux plus simples pour identifier plus facilement là où ça coince.
J'ai réussi à compiler hier pour ubuntu uniquement du moins je crois avoir réussi.

Je me suis dit qu'il y avait de grandes chances qu'ils soient partis depuis le tuto pour linux et non de mettre toutes les infos directement pour la cross compilation, et qu'il devait manquer des outils.. j'ai toujours pas retesté la cross compilation vu que j'ai fini à 23h (j'ai commencé très tard, chercher pour ma requalif m'a pris pas mal de temps). Apparemment dans tous les cas l'installation par exemple de mingw64 n'est plus à jour, je pensais que c'était une différence entre Debian et Ubuntu j'ai vite installé une Debian pour vérifier et on retrouve les mêmes problèmes quelqu'un de Ubuntu m'a aidé là dessus en fait maintenant quand on installe mingw les outils que la ligne de commande donnée par QEMU installent sont directement déjà installés, c'est pour ça que la ligne de commande ne fonctionne pas.

Je mets ça pour ceux qui seront dans la même galère (compilation de et pour Linux)

Pour la préparation de l'environnement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
sudo apt install mingw-w64 (installe aussi les modules dont on parle pour la version debian)
sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev
sudo apt-get install build-essential (installe un environnement pour le développement)
sudo apt-get install git (installe git)

Créer un repertoire dédié dans Documents (par exemple)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
mkdir ~/Documents/Build
cd ~/Documents/Build

Cloner les sources de QEMU

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3

git clone git://git.qemu-project.org/qemu.git

Configurer et compiler

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
cd qemu
mkdir -p bin/debug/native
cd bin/debug/native
# Configure QEMU 
../../../configure --enable-debug
# Start the build.
make

Pour tester je n'ai pas fait comme ils disent on dirait un lien
je l'ai lancé via ./qemu-system-x86_64-2 (l'ayant renommé pour vérifier qu'il n'y ait pas d'interférence avec ma version installée), ça se lance.

Je vais tenter la cross compil donc dans la foulée, et si j'y arrive je pense que je vais essayer de trouver un tuto pour mieux comprendre mingw, sous ubuntu il est en couleur alors qu'il est en n&b sur windows, déjà ça me rebute moins et je vais du coup voir pour comprendre les infos qu'il donne. Le truc c'est que sous windows quand tu vois l'avalange d'infos, pour distinguer le oui du non, les erreurs... c'est la plaie. Peut être que ça se configure mais en attendant c'est rédhibitoire.


edit:
Bon je pense avoir compris pour lancer la cross compilation

"configure" ne fait pas que configurer ça prépare le dossier à la compilation donc copie ou du moins liens/jonctions dossiers/fichiers

Quand on le fait suivre de make, apparemment il faut se mettre dans le dossier où l'on souhaite faire le travail, ensuite avec des liens relatifs lancer "configure", c'est pour ça qu'on peut voir ../../../configure X

Pour la cross compilation le mode sur la page ne fonctionne pas, apparemment il y a eu des évolutions, j'ai peu d'information pour ainsi dire pas du tout... Donc mon essai utilise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
./configure --host=i686-w64-mingw32 --enable-debug

J'espère ne pas me tromper

[daerlnaxe]

Je m'excuse de ne pas être très original je poste ce que j'ai mis sur un autre forum où l'on a aussi essayé de m'aider. Merci à toi Chrtophe d'avoir été là.



Donc fin mot de cette saleté !! Enfin ça a l'air, là il est 1h00 du matin et je suis défoncé. Je viens de vérifier 3 fois j'ai normalement réussi à le lancer, j'ai même renommé les exe au cas où car j'étais plus sûr que les variables d'environnement fonctionnaient aussi sous cmd, je crois pas mais j'ai préféré faire le parano.

Les DLL sont contenues dans Minwg64, le dossier est dans MSYS2/mingw64/bin. Je n'ai pas la moindre idée pourquoi le fait de compiler n'amène pas à une copie des dll ou bien si c'est en open source à les construire avec. J'ai commencé à copier quelques dlls pour vérifier puis comme j'ai vu que ça me levait des erreurs, mais qu'une autre dll manquait à chaque fois je me suis dit faisons l'inverse si c'est ça, mettons l'exe dedans. Plus aucune erreur il s'est mis à me demander le bios.


J'ai besoin de pousser plus loin mes investigations pour vérifier que tout fonctionne bien, et je verrais pour compiler du coup le patch.

En fait l'idée m'est venue en lisant comment compiler avec ça, j'ai lu des tutos avec des exemples basiques mais la plupart des gens semblaient lancer depuis MSYS2, et ça je ne comprenais pas, limite une compilation à la volée... C'était pas trop logique. Je cherchais une instruction pour lancer directement un exe quand j'ai trouvé une page où la personne disait qu'il était nécessaire de copier une dll de MSYS2 à côté de l'exe, et là je me suis dit... toi t'as besoin d'un environnement. C'était peut être pas le terme exact mais il me semblait clair que puisque le but était de recréer au fond une partie de linux pour compiler, il devait y avoir des liaisons là dedans au sein même de l'executable etc etc.

Si quelqu'un a une idée pour m'aider à comprendre pourquoi ça ne construit/copie pas les dlls avec l'exe je suis preneur. Quand je lance visual studio, j'ai régulièement x projets etc... même avec du c++/cli couplé à du c# j'arrive en général à réussir en bout à obtenir tout dans le même dossier (et pourtant c'est parfois bien ch...). A moins qu'en raison du fait que ça soit prévu pour linux donc modulaire, que ça soit pas prévu ainsi... J'aimerai bien comprendre.


Je ne sais pas pourquoi mais il est presque toujours 1h ou 2h du matin quand je me débloque.

[chrtophe]

Le rôle d'un compilateur est de compiler, pas de copier les dll.

La compilation d'un programme se fait en plusieurs phases :
- transformation du code source en code intermédiaire
- transformation de ce code en fichier objet

Sur un projet, tu vas avoir en général plusieurs fichiers .c chaque fichier .c sera transformé en fichier .o selon ce qui est présenté ci-dessus

A ce stade dans ton/tes fichier(s) .o, les fonctions externes à ton code contenu dans ton code sont vus comme des références non résolus.

Ensuite c'est au tour du linker (qui fait partie du processus de compilation) d'agir : il va prendre tous tes fichiers .o et les rassembler dans l’exécutable. Dans le cas de compilation statique, le code des fonctions externes appelés est intégré dans ton exécutable, dans le cas de compilation dynamique, des sections spécifiques sont ajoutés dans l’exécutable indiquant la liste des bibliothèques à charger dans l'espace d'adressage du processus.

C'est ensuite le système d'exploitation qui va charger ces bibliothèque par le biais de ses fonction internes de chargement d’exécutable, les bibliothèques dynamiques doivent être à l'endroit attendu (exemple essentiellement c:\Windows\system32 pour Windows et si non trouve dedans dans le dossier de l'exe ; /lib ou /lib64 pour Linux).

Ensuite tu as les makefile : ceux-ci vont te permettre d'affiner la compilation. En vulgarisant, tu peux voir ça comme un script spécialisé dans la compilation (le nombres de commandes accessibles hors compilation est réduit, tu n'as pas accès à toutes les commandes accessibles à un batch ou un script Shell). Exemple : si tu as plusieurs sources .c que tu en modifie une, make ne va pas recompiler tout, il va transformer le .c modifié en .o puis refaire l'édition de lien. Quand tu utilises Visual Studio par exemple, et que tu crée un projet, ça gère un makefile (ou équivalent spécifique Microsoft).

Sous Linux, quand tu compiles des sources, ça se passe souvent comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
./configure # génère le makefile pour ta configuration, vérifie que tu as les outils, les dépendances nécessaires
make # effectue la compilation proprement dite
make install # copie l'executable à son emplacement définitif et éventuellement les fichiers annexes (bibliothèques, fichier de configuration pour l'appli, autre fichiers comme des fichiers images appelés par l'appli, etc.)

Quand on te fourni une application (hors sources), sous Windows on va te fournir un installeur qui va se charger de copier les dlls au bon endroit, éventuellement installer les dépendances (redistributables C++, .net, etc.). Sous Linux soit tu installe depuis les dépôt (qui va récupérer le paquet correspondant à l'appli), soit tu as un paquet, et c'est le gestionnaire de paquet qui va faire le job (selon les instructions incluses dans le paquet), copier les fichiers au bon endroit, installer les dépendances si nécessaires, lancer des script de pre ou post installation.

[daerlnaxe]

Comme j'ai l'habitude d'ide et que j'ai appris en autodidacte ce sont des subtilités que je ne connaissais pas pour compiler/linker. C'est cool du coup que tu prennes le temps de m'expliquer, y'a des choses que je sais déjà et d'autres pas donc ça va m'aider à faire le lien sur toute cette histoire. Du coup je couche ce que je pense, ça peut m'aider moi pour plus tard et ça peut permettre qu'on m'aide (comme tu l'as fait). Je mets en gras ce qui pourrait m'aider à avancer si on m'oriente.

J'avais en effet compris qu'il y avait donc des références non résolues, mais le soucis c'est que je ne savais pas d'où ça provenait, pour moi le script avait pour rôle de faire le nécessaire ne sachant d'ailleurs pas si ces dll étaient déjà créées ou si donc elles allaient être compilées aussi à partir des sources. Vu que tu récupères dans les 5G de fichiers sources qu'on te dit de mettre tel ou tel package... En outre je me suis dit que vu que c'était porté sur windows ça aurait pu aboutir à un fichier exe contenant tout le code nécessaire à chaque fois. Le résultat est tellement chaotique en bout avec des exe mêlés avec des fichiers pour les headers et d'autres pour le code. et je continue de me demander s'il n'y a pas une interruption dans le script. Comme en fait un des mecs sur le projet (qui a expliqué ne pas compiler sous windows) dès le début m'a dit qu'il y avait un soucis avec glib2, que bizarrement en remettant propre le paquet sous msys2 je n'ai plus eu d'erreur, je me suis dit que c'était possible que ça vienne de ça.

"c:\Windows\system32" oui enfin là ça n'aurait eu aucun sens mais ok pour l'exemple. Par contre pour windows, quand je fais mes programmes je réutilise du code donc je me suis fait des librairies, elles seront avec mon programme, je peux aussi avoir une méthode pour en charger en c# après avoir lancé mon executable. Et enfin quand je suis sous visual studio en c# .netcore et que j'utilise des librairies natives et que je sors mon projet en "autonome" j'obtiens en bout un paquet avec toutes les dll nécessaires dans mon projet. Pareil si je fais un installer je vais voir où je mets mes dll mais ce qui est de mon crû je vais forcément le mettre au plus près de l'exe. Ce que je ne comprends pas ici, donc je vais reprendre le terme que tu m'as donné à l'avenir, c'est que le script n'intègre pas un linker, à moins que quelque chose ne casse ça au milieu, je sais qu'il y a une tâche qui s'arrête à 2/323 ou quelque chose du genre. Ou est ce que je peux lire tout ça ? C'est pas le fichier config visiblement on est d'accord ?

Donc on revenait au point précédent dans tous les cas, je savais bien que j'avais un soucis de dll j'en ai parlé mais personne ne pouvait me dire où les récupérer. Comment c'était géré par MSYS2 pour moi ça paraissait logique que le script aille faire le nécessaire dans le cas présent puisqu'il utilise ces packages.


Makefile, c'est l'interrogation, c'est pas moi qui le lance... Est ce que tu sais si quand tu fais make ça se lance dans la foulée, ou bien si on doit le lancer à la main ? Je ne sais plus si je l'ai lancé sous ubuntu ou windows tellement j'ai fait de manipulation, va falloir que je regarde.

Make install je crois avoir tenté sans succès, je vais réessayer...

tu aurais de la documentation expliquant pleinement le rôle de tout ça, j'étais parti ce matin pour aller lire celle de MSYS2, mais s'il y a moyen de gagner du temps.

Pour la différence windows / linux je savais mais par contre arriver à comprendre le mécanisme pour arriver à faire ça de l'un à l'autre.... Parce que le résultat que j'ai là pour moi c'est plus proche du fonctionnement de linux justement que de celui de windows, est ce que quelque chose ne fonctionne pas au milieu ou bien est ce que le tuto est mal fichu, je n'en ai aucune idée. Je me doutais depuis le début qu'on avait un soucis de cet ordre là, c'est le "comment" et "où" que je n'arrivais pas à comprendre. Et puis pour formuler ça, je me suis dit qu'avant de m'embarquer avec des termes peut être mal maitrisé et une analyse peut être faussée de linux vu que même si je connais les grands principes et que je l'utilise c'est toujours moins que windows et surtout que je n'ai fait que du python dessus , le mieux que j'avais à faire c'était de partir de 0 pour recevoir de l'aide. Mais j'ai trouvé beaucoup de monde au final qui n'étaient pas fan de mingw64 et MSYS2, et pour ainsi dire presque personne, toi je crois d'ailleurs et c'est tout, qui pouvaient m'en dire plus, je ne m'attendais pas à ça mais je le comprends car ce n'est pas simple à appréhender je trouve. J'ai l'impression quand même que cette histoire est profondément liée à la différence majeure de linux d'avec windows, qui est modulaire... Quand je regarde un peu que ça soit par MSYS2 ou même avec l'ajout de paquet au final là où l'on pourrait avoir une redondance de librairies sous windows, linux va permettre de s'appuyer sur les différents paquets connus et approuvés (en général).. qu'effectivement windows à part via .net framework et son contenu de base, si tu utilises une librairie utilisée par d'autres programmes mais qui n'est pas native tu vas généralement avoir une redondance de celle ci. Enfin je l'explique peut être mal mais c'est que je perçois en gros dans l'histoire... Pour ça que peut être que directement via MSYS2 certaines choses vont fonctionner mais sorti du contexte il faut obligatoirement recréé ce dont l'exe a besoin si le script ne se charge pas de faire le nécessaire.

Si je me trompe sur un point, n'hésite pas car ça m'aidera. Je me rends compte de la facilité de Visual Studio + .net etc... ça simplifie la tâche mais c'est vrai que du coup on se prive de comprendre certains points cruciaux.

edit: bon sang j'ai repensé à ma question sur make sur le chemin du retour, j'ai buggé. Donc je vais ouvrir makefile pour regarder. J'ai oublié qu'apparemment make se sert de makefile, comme je lance juste "make"

edit2: En fouillant je suis tombé sur Makefile.Ninja...

Dedans il y a dans les targets "qemu-version.h \" or ça finit comme ça... le 1/108 me chiffonne de même que le 2/35

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
make[1]: Leaving directory '/home/daerlnaxe/qemu/build'
changing dir to build for make ""...
make[1]: Entering directory '/home/daerlnaxe/qemu/build'
  GIT     ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
[1/108] Generating qemu-version.h with a custom command (wrapped by meson to capture output)
[2/35] Generating QAPI test (include) with a custom command
make[1]: Leaving directory '/home/daerlnaxe/qemu/build'

[chrtophe]

Et enfin quand je suis sous visual studio en c# .netcore et que j'utilise des librairies natives et que je sors mon projet en "autonome" j'obtiens en bout un paquet avec toutes les dll nécessaires dans mon projet.

Visual Studio, c'est pas qu'un IDE, mais un ensemble complet d'outils de développements.

edit2: En fouillant je suis tombé sur Makefile.Ninja..

Ninja est un système de build de sources :
https://ninja-build.org/manual.html

Je connaissais pas, j'ai regardé sur le net.

C'est probablement paramétré par configure.

je peux aussi avoir une méthode pour en charger en c# après avoir lancé mon executable.

Tu peux télécharger une bibliothèque depuis ton code aussi bien sous Windows que sous Linux, mais en général on ne fait pas comme ça.

make c'est assez bas niveau, les développeurs utilisent des outils plus haut niveau comme Visual studio par exemple.

Par contre pour les probs de compilation, ouvres plutôt un post dans les forums Programmation, on a dépassé le sujet de la virtualisation là.

[daerlnaxe]

Visual Studio, c'est pas qu'un IDE, mais un ensemble complet d'outils de développements.


Ninja est un système de build de sources :
https://ninja-build.org/manual.html

Je connaissais pas, j'ai regardé sur le net.

C'est probablement paramétré par configure.


Tu peux télécharger une bibliothèque depuis ton code aussi bien sous Windows que sous Linux, mais en général on ne fait pas comme ça.

make c'est assez bas niveau, les développeurs utilisent des outils plus haut niveau comme Visual studio par exemple.

Par contre pour les probs de compilation, ouvres plutôt un post dans les forums Programmation, on a dépassé le sujet de la virtualisation là.

C'est fait t'avais répondu d'ailleurs et hélas t'es le seul mais je peux en effet rappatrier le hic c'est que c'est le plus avancé ici... :/ JE me suis aussi posé la question.

sinon je suis en discussion avec des mecs de MSYS2 qui m'ont dit que el comportement n'était pas du tout normal, je suis en train de rechecker tout ça et j'ai lancé une nouvelle compilation. Le mieux c'est peut être que je ne poste plus le suivi en fait, qu'en penses tu ?

[chrtophe]

Je pense qu'ici ça n'a pas d’intérêt. Maintenant dans les posts programmation, si tu as des questions posées auxquelles tu as eu la réponse, ça peut être pertinent de la donner pour d'autres.