Reprise du message précédent :
le backtrace avec winedbg quand je veux executer notepad :

ça donne l'impression que wine a un problème quand il veut créer une interface graphique ( messages liés à  libxcursor.so.1 ), peut-être une incompatibilité avec le pilote radeon open source de ma carte graphique ati radeon HD4650 pcie ?

d'ailleurs quand je lance un programme DOS avec wine là il n'y a pas de plantage, vu qu'un programme DOS n'utilise pas d'interface graphique,

tu as quoi comme carte graphique Gee ?

free c'est en gros l'inverse de malloc.
Ca tente de liberer la memoire qui etait occupee par un object mais ca n'y arrive pas.
 
Pour une description plus exacte:

J'ai une radeon aussi, mais je tourne avec radeonsi et non pas r600g.
 
Apres pour dos je ne crois pas que wine soit vraiment utilisee, pour des applications dos wine invoque dosbox, c'est peut etre pour cela que ca fonctionne.

en fait il s'agissait d'un programme win32 mais sans interface ( qui tourne en mode console ), là wine arrive à le faire tourner sans planter,
 
c'est pour ça que j'ai l'impression que ça ne plante que si wine essaie de dessiner une interface
 
voici les dépendances de /usr/bin/wine :
 

 
et de /usr/bin/wine64 :
 

 
il y a peut-être un bug dans glibc 2.20 dont le paquet date du 14 septembre dernier qui est déclenché par une action de wine ?
 
j'ai voulu downgrader le paquet glibc mais c'est impossible :
 

ce ne serait pas une histoire de cache, avec ldconfig ?

http://linux.die.net/man/8/ldconfig

un truc qui a foiré lors de l'installation d'un paquet si un script d'installation avait été lancé et que ce script avait bogué ?

ces derniers jours j'ai compilé énormément de noyaux linux via un fichier pkgbuild, dont un fichier pkgbuild issu de AUR ( paquet linux-mainline ), peut-être qu'à ce moment là ça a merdé pour la génération du cache de ldconfig ?

Perso, j'ai un autre problème avec les polices de caractères dans les applications GTK (2 à priori).

C'est complètement aléatoire (et cela dure depuis environ 2 semaines). Pas vraiment trouver de solutions, ni de réels coupables à part peut-être la nouvelle version de Gtk3.
 
PS:Pilote libre radeon.

Loin d'être un pro, mais comme tu le dis, ça semble venir d'un très bas niveau, j'incriminerais même gcc sur ce coup là...

Ca semble être autre chose, c'était pas un assert qui crashait tout avant

oui le programme affiche un :

ensuite le backtrace :

Backtrace:

je remarque que le crash a lieu après l'appel à libxcursor.so.1, qui est une lib32 liée au serveur X, ça donne l'impression que dès que le programme necessite une interface graphique alors wine plante,

est-ce qu'il existe un moyen de lancer wine en dehors de KDE depuis un mode console pur ?

j'imagine qu'il faudrait lancer une session X avant, quelle est la commande en console pure ?

je cherche à savoir s'il n'y a pas un processus parasite lié à KDE qui fait planter wine,

je cherche aussi à savoir s'il y a des fichiers "cache" présents dans /usr, /var/cache, /etc que je pourrai supprimer ?
peut-être qu'il y a un cache corrompu

Je n'ai pas trop compris tes histoires de console pure.
Mais tu peux lancer 'startx' depuis un TTY et ca te lancera juste X (et probablement un xterminal).

le startx est programmé pour lancer KDE, j'ai lancé startx au lieu de KDM pour voir si le fautif n'était pas KDM mais wine continue de planter,
 
le seul truc que je n'ai pas testé c'est un environnement X tout simple ( pas de KDE ) surlequel wine pourrait se lancer,
 
en plus j'ai réinstallé l'intégralité des paquets de mon système via la commande :
 

 
mais ça n'a rien résolu, et pourtant tous les fichiers sont biens présents puisque j'ai réinstallé tous les paquets, d'où peut donc provenir le problème avec wine ?

Hmmm, la derniere fois que j'ai utilise startx il n'y a pas eu de KDE mais peut etre que ca a change, ou que ta configuration est differente.
 
Si tu as des doutes sur kde et que tu ne sais pas lancer X tout seul, tu peux toujours tenter fluxbox ou un autre DE minimaliste.
 
Apres, tu as peut etre des fichiers de configurations corrompus ou un truc du genre, difficile a dire.
Ou peut etre est-ce ta config?

Aussi j'ai un doute sur le 'e' de ton Qenq, je ne pense pas que tu le veuilles mais je peux me tromper.

le "e" de "pacman -Qe" signifie "lister tous les paquets explicitement installés", le "n" cible les paquets "natifs" présents dans la base de données synchronisée,

ça permet de réinstaller proprement tous les paquets déjà installés ( sauf ceux de AUR ),

concernant la session X j'ai utilisé les options de secours de KDM qui permettent de lancer une session X rudimentaire ( sans KDE, juste xterminal ), ça m'a permis de lancer wine et malheureusement de voir que j'avais encore le bug

on peut donc exclure un problème lié à KDE,

le filet se resserre, il nous reste donc à tester l'hypothèse d'un fichier de configuration présent dans /etc ou /usr ou /var qui serait corrompu, puis l'hypothèse d'un pilote vidéo radeon r600g bogué, et enfin l'hypothèse d'un GCC bogué puisque c'est lui qui a servi à compiler les paquets archlinux, ça bogue peut-être avec certains types de CPU ( j'ai un pentium dual core E6800 )

j'ai bien vérifié mes barettes avec memtest, pas d'erreurs

Justement je ne crois pas.
Tu oublies le 'explicitement'.
 
Par example:

ne retourne rien
 
pourtant:

 
et bien sur:

Ca me parait logique pour KDE mais en meme temps, on ne sais jamais d'ou ca peut venir..
 
Tu peux toujours tente en vesa sans r600g.
M'enfin si d'autres applications 3d fonctionnent, ca serait etonnant que wine non...

de mémoire tu peux lancer un X assez épuré avec un truc style "xinit -- /usr/bin/xterm", la syntaxe est pas forcément exacte

 
en effet si j’enlève le "e" je passe de 574 paquets à 1386
 
mais j'ose pas valider car je vois ces avertissements :
 

 
je vais tenter le coup du pilote vesa dans le xorg.conf

Donc il te reste pres de 800 paquets a reinstaller
 
Pour les avertissements, ils ne m'ont pas l'air bien mechant, mais a toi de voire. (Par contre ils sont bizarres, on penserait que pacman sache gerer ce genre de choses...)

donc tu me conseilles d’exécuter cette commande afin d'avoir tous les paquets ( même les dépendances ) réinstallés ?
 

 
sinon je viens d'essayer le pilote vesa dans le fichier xorg.conf mais ça n'a pas résolu le problème

Ah mais je ne n'ai jamais fait cela moi-meme, j'ai juste vu une faute dans ta commande
 
Apres le reste a toi de voir, mais ca me parait raisonnable.
 
Sinon as tu tente de reinstaller libxcursor et lib32 libxcursor?
Vu que ton soucis vient de l'un d'eux on dirait...

bon j'ai fini par lancer la commande, sauf que j'ai demandé que la réinstallation des dépendances ( vu que j'avais déjà réinstallé les paquets installés explicitements )

la commande s'est bien déroulée, réinstallation ultra rapide en moins de 5 minutes, 800 paquets de dépendances,

mais cela ne résout pas le bug,

mais finalement j'ai trouvé la solution après réflexion

c'était dû à une modification que j'avais faite il y a 2 semaines dans le fichier /usr/share/icons/default/index.theme, j'avais selectionné le thème "Oxygen_White" afin d'avoir le curseur de KDE dès le boot de X :

à force de voir "libXcursors" dans le backtrace ça m'a fait penser à cette modification qui est pourtant valable, je me suis dit alors "et si ça venait de cette modification du curseur par défaut du serveur X" ?

donc j'ai remis la valeur par défaut :

et là wine s'est mis enfin à fonctionner correctement

incroyable quand même que le simple fait de mettre un thème de curseur personnalisé peut entrainer un tel bug

Grave erreur IMO.
Tu viens de passer tous tes paquets non installés explicitement (donc installés comme dépendance) en 'installé explicitement'.
Maintenant TOUS tes paquets sont "installés explicitement".
Tu ne peux plus utiliser correctement un "pacman -Rs" de façon "normale". C'est pas dramatique, tu peux utiliser "-Rss" pour forcer la suppression des dépendances installées explicitement.
Perso je suis hyper maniaque de ma base de pacman et jamais j'aurais fait ce que tu viens de faire car il y a une grosse perte d'infos    
 
Tu aurais du faire
packages explicites | pacman -S -
packages de dépendance | pacman -S --asdep -

 
Le truc qui on dirait n'a rien avoir et pourtant...
Je dirais de creer un bug quelque part, mais je ne sais meme pas ou il faudrait le faire...

oui c'est un sacré bug, je pense que j'ai en fait découvert un bug du serveur X qui entraine un crash de wine,
 
car normalement le fait de spécifier un curseur personnalisé dans la configuration du serveur X ne devrait pas créer de tels problèmes
 
c'est grâce au backtrace que j'ai fait la liaison entre libxcursor et le thème de curseur du serveur X, car par élimination la seule hypothèse qui tenait c'était le cas du fichier de configuration qui fout le bordel
 
 

 
pourtant quand je refais un "pacman -Qdnq" je retrouve la même liste de 800 paquets de dépendances,
 
à mon avis il y a pas de problèmes, rien n'a changé, parce que les paquets que j'ai réinstallé étaient donc déjà installés, donc pacman a tout simplement conservé le même motif d'installation ( "dépendance" ou "installé explicitement" selon le contexte ),
 
c'est logique car il arrive souvent de devoir réinstaller manuellement un paquet ( en faisant un pacman -S nom_du_paquet ) et cela n'a jamais transformé le motif d'installation si ce paquet était une dépendance
 
là par exemple je viens de taper ceci :
 

 
et ça me dit toujours que le paquet a été installé comme une dépendance d'un autre paquet

Tu as de la chance alors
A mon avis c'est un changement de comportement récent d'ailleurs.

d'après le wiki ça a l'air d'être ça :
 

 
https://wiki.archlinux.org/index.ph [...] endency.3F
 
ils disent que le "-S" préserve le motif d'installation par défaut
 
en tout cas tous ces bugs ( le kernel 3.17 qui freeze aléatoirement au boot, le wine qui déconne ) m'arrivent alors que je vais bientôt fêter ma première année complète passée sous archlinux    
 
bon en réalité ça fait 3 ans ( 2 ans via une machine virtuelle et 1 an en tant qu'OS principal )

 
pour ce bug le coupable a été identifié, plus d'infos sur cet autre topic :
 
http://forum.hardware.fr/forum2.ph [...] 0#t1368299

une nouvelle version de grub est disponible dans le dépôt officiel stable,
 
elle apporte comme fonctionnalité la détection automatique du fichier intel-ucode.img ( lors de la génération par le script grub-mkconfig du fichier grub.cfg ) si ce fichier est présent dans le répertoire /boot,
 
il n'est donc plus nécessaire de modifier manuellement le fichier grub.cfg pour ceux qui avaient utilisé cette méthode pour la prise en compte du fichier microcode intel

Ca c'est chouette

T'as lu ça ou, parce que ça ne semble pas fonctionner chez moi, j'ai viré ma modif du 10_linux et quand je lance grub-mkconfig je n'ai aucune allusion au fichier intel-ucode.img.
la dernière version date d'hier, c'est la 1:2.02.beta2-5, c'est bien celle que j'ai pourtant
 
edit: effectivement : https://wiki.archlinux.org/index.php/microcode

reedit: je suis un boulet, c'est leur modif que j'ai viré du 10_linux, pas la mienne  

Pourtant si tu avais déjà modifié le fichier, tu aurais du avoir un pacnew...

bah non rien du tout

Tu avais peut-être la même modification à l'octet près

Non, justement la ils utilisent la fonction make_system_path_relative_to_its_root que je n'ai surement pas utilisé vu que je ne connaissais pas

 
Est-ce que quelqu'un sait ce que l'on "loupe" comme fonctionnalités en ne chargeant pas ce firmware lors du boot ?

Ca depend de ton processeur.

J'essaye depuis 5 heures d'installer Arch sur mon dell precidio', j'ai testé avec uefi, sans uefi avec gpt, sans uefi avec mbr, ça merde toujours. La distrib boot mais je me mange un warning "wrong partition table" ...

il faut faire abstraction de la distribution et voir déjà si le boulot de partitionnement a bien été fait correctement, en utilisant par exemple gparted live cd, tu vires toutes les partitions existantes puis tu en crées de nouvelles proprement ( une partition primaire "/", puis une partition étendue qui contiendra une partition logique swap et une partition logique "home" )
 
en mode mbr tout ce qu'il y a plus de classique ça doit démarrer avec grub ou syslinux sans messages d'erreurs
 
http://gparted.org/h2-fix-msdos-pt.php

A priori le plus simple c'est de faire du mbr sans uefi non ?

oui il me semble si ta partition ne fait pas plus de 2 To :
 
https://wiki.manjaro.org/index.php? [...] S_v/s_UEFI
 
dans le bios uefi il faudra sans doute vérifier s'il y a une option "legacy bios compatibility" à activer

Si ça chie au niveau du boot avec une erreur aussi énorme, c'est que tu n'as pas du déceler que tu avais fait un truc pas comme il fallait pendant l'installation.
Recommence

Voila donc une arch tout neuve sur le dell M4700, je vais le passer à 32 Go de Ram en conf full 64 bits

TODO list :

- contrôle luminosité écran
- configuration touchpad
- custom dwm / vim / urxvt
- Texlive
- R / Rstudio (chier Rstudio est dans AUR :-/ )

Le driver ATI radeonSI est pas mal du tout pour la Firepro M4000