[gull] Symboles non résolus au chargement de modules

[Julien Escario]

Bonjour,
Je planche en ce moment sur un problème avec un système embarqué.

J'ai deux machines : l'hôte (un pc portable tout ce qu'il y a de plus classique) 
et la cible (un système embarqué powerpc).

J'ai créé un environnement de cross-compilation à l'aide de buildroot. GCC 
3.3.5, binutils 2.16.1, kernel-headers 2.4.25 et uClibc 0.9.28. Ca date un peu 
mais ce sont les réglages proposés par défaut par buildroot (hormis GCC que j'ai 
downgradé).
Ensuite, à l'aide de tout ça, j'ai créé un kernel à base d'un vanilla 2.4.25 
pour powerpc (make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc- vmlinux). Le 
bootloader sur le powerpc est U-Boot qui indique dans la doc de faire :
$ powerpc-linux-uclibc-objcopy -O binary -R .note -R .comment -S vmlinux
$ linux.bin
$ gzip -9 linux.bin
$ mkimage -A ppc -O linux -T kernel -C gzip -a 0 -e 0 -n "Linux Kernel Image" -d 
linux.bin.gz pImage
pImage est ensuite le binaire récupéré par TFTP pour booter.
Buildroot m'a également créé, en même temps que le cross-compilateur, un système 
de fichiers ext2 monté par NFS.
Jusque là, tout marche trés bien.

Le problème intervient lorsque je tente de charger les modules qui ont été 
compilés en même temps que mon noyau.
(là je fais dire de tête parce que je n'ai pas les logs sous les yeux).
Je copie donc *hote*:/lib/modules/2.4.25/ vers la cible, au dans le meme répertoire.
$ depmod -a
me renvoie pleins d'erreurs concernant des symboles non résolus (tel que __cli 
qui est hyper classique). Note : les modules n'ont pas de dépendance.
Si maintenant je copie le fichier System.map trouvé dans /usr/src/linux-2.4.25/ 
vers la cible et que je fais :
$ depmod -F /usr/src/linux-2.4.25/System.map -a
Là, ca fonctionne, les fichiers /lib/modules/2.4.25/modules* sont bien écrits. 
D'ailleurs on voit bien à ce moment là qu'ils n'ont pas de dépendance, les vides 
sont presque vides.
Mais si je fais :
$ insmod usbcore.o
par exemple, alors les symboles non résolus sont de retour (et insmod n'a pas de 
-F).

D'ou mon interrogation : comment fonctionne le système des symboles kernel. J'ai 
deux pistes : /proc/ksyms et System.map mais je ne comprend pas pourquoi il y a 
tous ces symboles non résolus.
C'est long mais j'ai essayé d'être le plus précis possible, désolé.

Qqun aurait-il une idée ou une clarification sur les symboles ?

Bonne journée,
Julien