Je viens de voir que les sources CVS de Qemu corrigent le bug qui
m'enpêchent d'utiliser mon lecteur de disquette.
Je souhaite donc les compiler, mais j'ai l'erreur suivante :
On Fri, 13 Feb 2004 19:33:05 +0100, Olivier Viennet wrote:
(...)
/usr//bin/ld: cannot find -laudio (...)
Après recherches, laudio semble se rapporter à libaudiofile0.
si le lieur dit -laudio, ce n'est pas -laudiofile0 ! c'est bien libaudio.so que le lieur doit trouver sur le système. Sur ma distribution, c'est un paquetage appellé libnas2-devel qui le fournit. Plus d'info : http://radscan.com/nas.html
Gérard Patel
On Fri, 13 Feb 2004 19:33:05 +0100, Olivier Viennet <anonyme@free.fr>
wrote:
(...)
/usr//bin/ld: cannot find -laudio
(...)
Après recherches, laudio semble se rapporter à libaudiofile0.
si le lieur dit -laudio, ce n'est pas -laudiofile0 !
c'est bien libaudio.so que le lieur doit trouver sur le système.
Sur ma distribution, c'est un paquetage appellé libnas2-devel
qui le fournit.
Plus d'info :
http://radscan.com/nas.html
On Fri, 13 Feb 2004 19:33:05 +0100, Olivier Viennet wrote:
(...)
/usr//bin/ld: cannot find -laudio (...)
Après recherches, laudio semble se rapporter à libaudiofile0.
si le lieur dit -laudio, ce n'est pas -laudiofile0 ! c'est bien libaudio.so que le lieur doit trouver sur le système. Sur ma distribution, c'est un paquetage appellé libnas2-devel qui le fournit. Plus d'info : http://radscan.com/nas.html
Gérard Patel
Olivier Viennet
gerard patel wrote:
Sur ma distribution, c'est un paquetage appellé libnas2-devel
Jamais je n'aurais pensé à un truc pareil !
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ? Je dois mal chercher, car je ne trouve rien ... Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ? Ou quels sont les mots clés donner google ?
Merci
Olivier Viennet
gerard patel wrote:
Sur ma distribution, c'est un paquetage appellé libnas2-devel
Jamais je n'aurais pensé à un truc pareil !
Mais maintenant la nouvelle erreur est :
/usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ?
Je dois mal chercher, car je ne trouve rien ...
Plutôt que de poser encore vingt fois la même question, ou peut-on trouver
les correspondances des sigles avec les noms complets ? Ou quels sont les
mots clés donner google ?
Sur ma distribution, c'est un paquetage appellé libnas2-devel
Jamais je n'aurais pensé à un truc pareil !
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ? Je dois mal chercher, car je ne trouve rien ... Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ? Ou quels sont les mots clés donner google ?
Merci
Olivier Viennet
TiChou
Dans l'article news:, Olivier Viennet écrivait :
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ?
La librairie X Toolkit.
Je dois mal chercher, car je ne trouve rien ...
Oui.
Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ?
-lmachin -> libmachin, on ne peut pas plus simple. Et selon que la librairie soit partagée (shared) ou statique (static), l'extension sera .so ou .a.
Ou quels sont les mots clés donner google ?
libmachin+nom de la distribution
Merci
De rien.
-- TiChou
Dans l'article news:2302191.68k3m7ZnSD@news.free.fr,
Olivier Viennet <anonyme@free.fr> écrivait :
Mais maintenant la nouvelle erreur est :
/usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ?
La librairie X Toolkit.
Je dois mal chercher, car je ne trouve rien ...
Oui.
Plutôt que de poser encore vingt fois la même question, ou peut-on trouver
les correspondances des sigles avec les noms complets ?
-lmachin -> libmachin, on ne peut pas plus simple. Et selon que la librairie
soit partagée (shared) ou statique (static), l'extension sera .so ou .a.
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ?
La librairie X Toolkit.
Je dois mal chercher, car je ne trouve rien ...
Oui.
Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ?
-lmachin -> libmachin, on ne peut pas plus simple. Et selon que la librairie soit partagée (shared) ou statique (static), l'extension sera .so ou .a.
Ou quels sont les mots clés donner google ?
libmachin+nom de la distribution
Merci
De rien.
-- TiChou
g.patel
On Fri, 13 Feb 2004 20:59:48 +0100, Olivier Viennet wrote:
(...)
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ? Je dois mal chercher, car je ne trouve rien ... Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ?
1 : -lXt -> on cherche libXt.so en général le .so est un lien symbolique vers la 'vraie' librairie, mais le lien est installé comme n'importe quel fichier. Donc :
Par contre, avec rpm, il faut essayer les principaux chemins possibles pour une librarie (/lib, /usr/lib, /usr/X11R6/lib, etc...). C'est moins pratique.
Si c'est une distribution non basée sur rpm, là je ne sais pas.
Gérard Patel
On Fri, 13 Feb 2004 20:59:48 +0100, Olivier Viennet <anonyme@free.fr>
wrote:
(...)
Mais maintenant la nouvelle erreur est :
/usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ?
Je dois mal chercher, car je ne trouve rien ...
Plutôt que de poser encore vingt fois la même question, ou peut-on trouver
les correspondances des sigles avec les noms complets ?
1 : -lXt -> on cherche libXt.so
en général le .so est un lien symbolique vers la 'vraie' librairie,
mais le lien est installé comme n'importe quel fichier.
Donc :
Par contre, avec rpm, il faut essayer les principaux chemins
possibles pour une librarie (/lib, /usr/lib, /usr/X11R6/lib, etc...).
C'est moins pratique.
Si c'est une distribution non basée sur rpm, là je ne sais pas.
On Fri, 13 Feb 2004 20:59:48 +0100, Olivier Viennet wrote:
(...)
Mais maintenant la nouvelle erreur est : /usr//bin/ld: cannot find -lXt
Qu'est ce que c'est ? Je dois mal chercher, car je ne trouve rien ... Plutôt que de poser encore vingt fois la même question, ou peut-on trouver les correspondances des sigles avec les noms complets ?
1 : -lXt -> on cherche libXt.so en général le .so est un lien symbolique vers la 'vraie' librairie, mais le lien est installé comme n'importe quel fichier. Donc :
Par contre, avec rpm, il faut essayer les principaux chemins possibles pour une librarie (/lib, /usr/lib, /usr/X11R6/lib, etc...). C'est moins pratique.
Si c'est une distribution non basée sur rpm, là je ne sais pas.
Gérard Patel
g.patel
On Fri, 13 Feb 2004 21:50:46 GMT, (gerard patel) wrote:
1 : -lXt -> on cherche libXt.so
bon, comme il a été signalé par ailleurs, ça peut aussi etre une archive (libXt.a)
Gérard Patel
On Fri, 13 Feb 2004 21:50:46 GMT, g.patel@wanadoo.fr.invalid (gerard
patel) wrote:
1 : -lXt -> on cherche libXt.so
bon, comme il a été signalé par ailleurs, ça peut aussi
etre une archive (libXt.a)
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
On Fri, 13 Feb 2004 19:33:05 +0100, Olivier Viennet wrote:
Re-bonjour,
J'ai résolu mon précédent : il me manquait les librairies
glic-static-devel et libalsa2-satic-devel.
Par contre, j'ai maintenant l'erreur de compilation suivante :
Le piège, c'est que qemu-i386 est compilé en statique et que certaines
librairies ne sont pas toujours disponibles en archives.
Je te conseillerais d'ignorer le problème en ne compilant pas cette
version et en utilisant la version i386-slowmmu.
En effet, la version i386 est plus rapide mais extrèmement expérimentale.
La version slowmmu est plus lente, puisque la MMU du processeur est
entièrement émulée par qemu, mais marche mieux.
Pour faire celà, fait:
./configure --target-list="i386-slowmmu" && make
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
Olivier Viennet
Bonjour,
Et merci à tous pour vos conseils ... je progresse, librairie après librairie !
Olivier
Bonjour,
Et merci à tous pour vos conseils ... je progresse, librairie après
librairie !
Et merci à tous pour vos conseils ... je progresse, librairie après librairie !
Olivier
Olivier Viennet
no_spam wrote:
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul. mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de disquette : Qemu veut toujours me la formatter !
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au cdrom.
A+
Olivier V
no_spam wrote:
Le piège, c'est que qemu-i386 est compilé en statique et que certaines
librairies ne sont pas toujours disponibles en archives.
Je te conseillerais d'ignorer le problème en ne compilant pas cette
version et en utilisant la version i386-slowmmu.
En effet, la version i386 est plus rapide mais extrèmement expérimentale.
La version slowmmu est plus lente, puisque la MMU du processeur est
entièrement émulée par qemu, mais marche mieux.
Pour faire celà, fait:
./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul.
mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de
disquette : Qemu veut toujours me la formatter !
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au
cdrom.
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul. mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de disquette : Qemu veut toujours me la formatter !
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au cdrom.
A+
Olivier V
no_spam
On Sat, 14 Feb 2004 18:29:54 +0100, Olivier Viennet wrote:
no_spam wrote:
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul. mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de disquette : Qemu veut toujours me la formatter !
J'ai du code qui formatte sous DOS et Linux, mais pas sous Windows. Il n'est pas encore dans le CVS, car j'ai encore des problèmes avec certains OS (dont des certains Linux). L'émulation de la DMA est buggée, et Windows utilise une technique assez étrange pour gérer la DMA, ce qui le fait freezer sous qemu lors des accès aux disquettes (il ne gère pas les timeouts sur la disquette, apparement).
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au cdrom.
Pour le CDROM, il faut lancer un driver DOS pour qu'il marche sous Windows.
On Sat, 14 Feb 2004 18:29:54 +0100, Olivier Viennet wrote:
no_spam wrote:
Le piège, c'est que qemu-i386 est compilé en statique et que certaines
librairies ne sont pas toujours disponibles en archives.
Je te conseillerais d'ignorer le problème en ne compilant pas cette
version et en utilisant la version i386-slowmmu.
En effet, la version i386 est plus rapide mais extrèmement expérimentale.
La version slowmmu est plus lente, puisque la MMU du processeur est
entièrement émulée par qemu, mais marche mieux.
Pour faire celà, fait:
./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul.
mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de
disquette : Qemu veut toujours me la formatter !
J'ai du code qui formatte sous DOS et Linux, mais pas sous Windows.
Il n'est pas encore dans le CVS, car j'ai encore des problèmes
avec certains OS (dont des certains Linux).
L'émulation de la DMA est buggée, et Windows utilise une technique
assez étrange pour gérer la DMA, ce qui le fait freezer sous qemu
lors des accès aux disquettes (il ne gère pas les timeouts sur
la disquette, apparement).
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au
cdrom.
Pour le CDROM, il faut lancer un driver DOS pour qu'il marche
sous Windows.
On Sat, 14 Feb 2004 18:29:54 +0100, Olivier Viennet wrote:
no_spam wrote:
Le piège, c'est que qemu-i386 est compilé en statique et que certaines librairies ne sont pas toujours disponibles en archives. Je te conseillerais d'ignorer le problème en ne compilant pas cette version et en utilisant la version i386-slowmmu. En effet, la version i386 est plus rapide mais extrèmement expérimentale. La version slowmmu est plus lente, puisque la MMU du processeur est entièrement émulée par qemu, mais marche mieux. Pour faire celà, fait: ./configure --target-list="i386-slowmmu" && make
Content de te retrouver ... !
J'ai réussi à compiler avec ./configure seul. mais les nouvelles sources du CVS ne résolvent toujours pas mon problème de disquette : Qemu veut toujours me la formatter !
J'ai du code qui formatte sous DOS et Linux, mais pas sous Windows. Il n'est pas encore dans le CVS, car j'ai encore des problèmes avec certains OS (dont des certains Linux). L'émulation de la DMA est buggée, et Windows utilise une technique assez étrange pour gérer la DMA, ce qui le fait freezer sous qemu lors des accès aux disquettes (il ne gère pas les timeouts sur la disquette, apparement).
Par contre sous Bochs, j'ai accès à ma disquette, mais pas non plus au cdrom.
Pour le CDROM, il faut lancer un driver DOS pour qu'il marche sous Windows.