Salut à tous !
 
J'ai installé ma petite Suse, et comme j'utilise une carte son Aureal 8820 (Le premier qui se marre ), que je dois donc compiler à part avec des drivers du projet sourceforge. Le problème est que la compilation de ce module demande les headers du noyau, comme ils étaient dispos pour la Debian sur laquelle le module marche très bien, mais je n'ai pas réussi à installer ces headers sur la Suse (pas trouvé ...).
J'ai donc installé les sources, compilé le module non sans petits messages d'erreur, et lorsque je veux charger mon module il me dit qu'il a été compilé avec GCC-2. Or dans la Suse 8.2, aucune trace de GCC2 !
 
En faisant un insmod -f, j'ai trouvé des unresolved symbols en plus du message d'erreur de compilation GCC-2, ce qui m'amène à penser que le souci ne vient pas de la version de GCC utilisée (un message d'erreur générique sans doute ...) mais plutôt des headers qui n'ont pas été trouvés, ce qui fait que le module se compile un peu n'importe comment et pas du tout spécifiquement au noyau Suse. Mais je peux me tromper ...
 
J'aîmerai donc savoir si vous avez recontré ce type de problèmes, comment installer les headers du noyau ou simplement compiler un module correctement sous Suse (sous Debian ca marchait super ...), et s'il existait un driver pour ma carte son directement de chez Suse ...

Question stupide, je crois que j'ai trouvé la solution ...
http://sdb.suse.de/en/sdb/html/chofman_vortex.html
 
 
 
 
 
 
... et vous en pensez quoi de la Suse vous ?

Bon, en fait la question n'était pas si stupide que ca ... ca ne marche toujours pas
 
J'ai le malheureux message d'erreur compilation GCC-2 alors que j'utilise GCC-3 ... une idée ?

et en installant glibc-devel, tu peux pas compiler après ?

Installer glibc-devel pour compiler un module du noyau ?

les headers du noyau sont dedans

Parfait merci (avec un peu de retard ), je vais tester ca

Euh ... je viens de regarder, et le glibc-devel est installé d'office, et ne semble pas résoudre mon problème. C'est curieux qd même comme message d'erreur non ?

regarde ta version de modutils
 
rpm -q modutils
 
je me suis fait avoir y a pas longtemps avec le kernel de la suse (que j'utilise mais sous RH 8.0)
 
en fait sous RH 8.0, c'est modutils-2.4.18, ça passait très bien mais en recompilant le noyau de la suse il y a quelques jours, je me suis retrouvé avec des messages d'erreurs d'insmod au boot et une palanquée d'unresolved symbols, ce qui m'empêchait bien sûr de compiler le module de ma carte réseau et de ma carte graphique (nvnet et nvidia), je suis passé à la version modutils-2.4.20 (celui de la RH 9), même soucis alors que ça passait très bien pour un noyau 2.4.21-rcX(-acX)... pas du genre à lâcher prise, je me lance sur modutils-2.4.25 qui se trouve dans la file rawhide, résultat : plus de problème, insmod ne gueule plus au démarrage et mes modules sont corrects  
 
ce que je ne comprends pas, c'est que j'en suis à ma 4ème compile sur ce noyau 2.4.20 suse et que c'est seulement à cette compilation que ça pose problème et pas sur les précédentes
 
finalement, je me demande si tu n'aurais pas le même problème
 
il existe un petit script perl qui détecte les erreurs après avoir compilé les noyau et ses modules, il s'appelle "reference_discarded.pl" et est facilement trouvable par google, ça permet de voir directement si le noyau est OK ou non avant de l'installer
 
edit : vérifie bien qu'à la compilation les headers utilisés sont bien ceux du noyau et non de /usr/include/linux, ça pose problème parfois aussi

Alors, mes modutils sont les 2.4.22-33, tu penses que je devrais les recompiler ?
En ce qui concerne le script Perl, il te donnes plus d'infos sur le chargement de tel ou tel module non ?
Le Makefile du driver que je veux compiler pointe effectivement ses includes vers /usr/src/linux/... : ou se trouve réellement les headers du noyau ?

D'ailleurs, je viens d'installer la dernière version de modutils en rpm et ca ne semble pas changer gd chose ... de même le script perl ne donne pas vraiment d'infos intéressantes.