From: Cedric Le Goater (clg_at_fr_dot_ibm_dot_com)
Date: Wed Jul 25 2007 - 08:24:17 PDT
> Hmm, not 100% sure on that one. There is code in > cr_module/cr_module.c:cr_init_module() that compares the addresses of > two symbols as probed from the System.map at configure time against > their addresses as resolved by the kernel's module linker/loader. BLCR > refuses to load the module if these don't match, since it will be making > function calls to other addresses obtained in the same way (and we > really don't want to invoke code at random addresses in kernel context). > > So, my best guess is that message means what it says, perhaps due to > BLCR's autoconf machinery locating the wrong System.map file. You > should try comparing the output of > $ grep register_chrdev /proc/kyms > against that of > $ grep register_chrdev [MAPFILE] > where [MAPFILE] is the System.map file being used by BLCR (try "grep > LINUX_SYMTAB_FILE Makefile" in your BLCR build directory). If they > match, then it is possible that something is happening with respect to > kernel linking/relocation that BLCR is not prepared to deal with. If > they don't match then it might still be a relocation issue, but more > likely it means BLCR found the wrong System.map file. If that is the > case, try passing --with-system-map=[WHATEVER] when configuring BLCR. > Let us know what you find. hmm, the addresses in the /boot/System.map-2.6.22.1-27.fc7 file and the ones from /proc/kallsyms (same kernel shipped by fedora) are different. weird. I'll investigate. >> what about glibc 2.6 ? > > What about it? I don't have any systems running glibc 2.6. If you have > specific problems (once past the System.map problem), please let us know > and we'll see what we can do to sort them out. I will as soon as i get that module loaded ! :) Thanks, C.