After replacing /usr/include/linux/version.h with /usr/src/linux-2.4.17/include/linux/version.h, the module is now built with the correct kernel version information. However, whenever I attempt to insmod it I get complaints of unresolved symbols:
Using /lib/modules/2.4.17/misc/cpint.o /lib/modules/2.4.17/misc/cpint.o: unresolved symbol __copy_to_user_fixup /lib/modules/2.4.17/misc/cpint.o: unresolved symbol __copy_from_user_fixup /lib/modules/2.4.17/misc/cpint.o: By editing cpint's Makefile and changing the INCLUDEDIR to /usr/src/linux-2.4.17/include/,however, the module will work fine. This make me wonder whether I can expect more problems with these include libraries left over from my RH kernel. Michael Lambert ---Original Message---------- Odd. On my SuSE 7.0 system they're symlinks: > ls -l /usr/include/asm /usr/include/linux lrwxrwxrwx 1 root root 29 Feb 23 2001 /usr/include/asm -> ../src/linux/include/asm-s390 lrwxrwxrwx 1 root root 26 Feb 23 2001 /usr/include/linux -> ../src/linux/include/linux I had to double-check that because the coloring scheme SuSE uses has the same color for directories as symbolic links. :( You need to make sure that /usr/include/linux/version.h matches your currently running kernel level. On my Intel 2.4.18 system, I have: #define UTS_RELEASE "2.4.18" #define LINUX_VERSION_CODE 132114 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) Yours should say #define UTS_RELEASE "2.4.17" but I have no idea what the value would be for LINUX_VERSION_CODE. You could probably get that from /usr/src/linux-2.4.17-SuSE/include/linux/version.h Mark Post
