How to Avoid The Unresolved Symbols Error
If you keep getting an unresolved symbols error when using ALSA modules, the solution is very simple: Clean the kernel's source tree.Change directory to the kernel source tree If you want to keep the same config, I advise.:
CP .config / TMP (Not Inside the Current Directory, IT WILL GET ERSED)
Make Mrproper
CP /TMP/.config.
Make oldconfig
Make Dep
Make Bzimage
Make modules
Make modules_install
- Copy your new kernel image file bzImage to your boot device location as you'd normally do.Then, recompile ALSA.I know that this is not directly ALSA related, but it could take placein the FAQ, as it definitely prevents ALSA from working .
TRY THIS: in The Alsa-Driver Directory,
RM config.cache
./configure [your option]
Make clean
Make
And Then, As root, do:
Make Install
RMMOD -A / _ THESE MAKE Sure No Old Modules Are Hanging Around In Memory
RMMOD -A /
Maybe Some Partially-Compiled Files Arement.remove All of the ALSA KERNEL MODULES BEFORE You Do "make install". Do a "find / lib / modules /` uname -r` -name 'SND * .O '"To make Sure They're All Gone.on Thu, 8 Mar 2001, Narayana, Venkat A. Wrote:> Hi,> I am Learning to Write Kernel Modules, and while experimenting> with a Simple Module, I Got>" hello.o: unresolved symbol printk_Rsmp_1b7d4074 "error> while loading this module via insmod hello.o command >> i noticed that / proc / ksyms contains printk symbol >> What is that i am doing which is not correct> Help me..? out.As other people have pointed out this has to do with versioning.The simple answer to the question is that you need to include modversions.hbefore the header file for printk if you want the module to load into a kernel with CONFIG_MODVERSIONS turned on. You Could Do this in Two Ways: in Each of Your C Files, At the top (Before You #include Linux / kernel.h), you could have:
#ifdef config_modversions
#include
#ENDIF
Or in Your makefile, you Could Have
IFDEF Config_Modversions
CPPFLAGS = -include /usr/src/linux/modversions.h
ENDIF
NOW, I'll Try and Explain How IT All Works. (Jay, A Section On THIS Definitely Needing;). Okay, this Can Be A Bit Difficult To Explain, But I'll Give It A Go I'VE Probably Got Some of It Wrong. Someone Will Correct Me. (All this ass config_modversions is turned on)
............................................. ...CRIPLILE, TELEGEM.
SO What Does this do? Well, if you have a look at modversions.h, it incrudes Loads of .ver files. Each of these files have loads of lines like (in ksyms.ver) #define __ver_printk 1b7d4074
#define printk _Set_Ver (Printk)
THIS Winds Up Having a #define along the line of # define printk printk_r1b7d4074
SO What Does this do? Well, Now Evewhere Printk is Mentioned it gets
Replaced by Printk_r1b7d4074 by the preProcessor. So When THE KERNEL IS Compiledthere Is No Such Function As Printk, There is Only One Called Printk_r1b7d4074.
SO if you want to write a module this uses the 'Printk' Function (Sorry, I mean the printk_r1b7d4074 function) You're going to have to include modversions.h before printk is defined.
Another Question you might assek is how the .ver files get generated?
Well the Basic Command IS Along The Lines of
GCC -E -D__genksyms__ R-file> The GCC Command Puts The C File Through The Preprocessor with __genksyms__ defined The Output of this is passed through to genkyms Which generates output like #define __VER_PRINTK 1B7D4074 #define printk _Set_Ver (Printk) Where the 1b7d4074 depends on the kernel version you support. Hi, I Have Gone Through An Alsa Compilation Which Went Well, But The Loading of The Module Came Back with the Following Error: /LIB/Modules/2.2.17/misc/snd.o: unresolved Symbol Unregister_Sound_DSP /LIB/Modules/2.2.17/misc/snd.o: unresolved Symbol register_sound_dsp /LIB/Modules/2.2.17/misc/snd.o: unresolved Symbol Unregister_sound_special /LIB/Modules/2.2.17/misc/snd.o: unresolved symbol register_sound_special /LIB/Modules/2.2.17/misc/snd.o: insmod /lib/modules/2.2.17/misc/snd.o Failed /LIB/Modules/2.2.17/misc/snd.o: insmod SND-CS4236 failed I then went to the FAQ which said that it was because my kernel was incorrectly configured andalso because I had missed out the soundcore code (CONFIG_SOUND = y) .I was surprised because I had just recompiled that kernel, ensuring that I had added the right options.Apparently - I noticed this on some kernel mailing lists - the usage of the kernel modversions facility (CONFIG_MODVERSIONS) is not always correctly taken into account by the fastdep kernel makefiles reconfiguration system.The result is weird symbol names for some symbols.
