Undefined symbols

Starting with 2.4.0-test11 kernels, I am getting a whole bunch of undefined symbols when trying to load modules. Strange thing is that the undefined symbols are exported from the kernel. For example, when loading the BigSur sound driver I get:

     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol remap_page_range
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol schedule_timeout
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol __wake_up
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol kmalloc
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol free_irq
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol remove_wait_queue
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol del_timer
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol interruptible_sleep_on
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol __pollwait
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol kfree
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol request_irq
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol add_wait_queue
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol mem_map
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol jiffies
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol printk
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     unresolved symbol add_timer
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     insmod
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o
     failed
     /lib/modules/2.4.0-010109-59smp/kernel/drivers/sound/cs4281.o:
     insmod cs4281 failed

Symbols such as printk and jiffies are exported in /proc/ksyms:

     [root@borg linux]# egrep ' (jiffies|printk)' /proc/ksyms
     e000000000b44c58 jiffies_R__ver_jiffies
     e000000000a869f0 printk_R__ver_printk

However, cs4281.o references the symbols without the version string attached:

     [root@borg linux]# nm cs4281.o | egrep ' (jiffies|printk)'
                      U jiffies
                      U printk

What am I missing here? I am using modutils-2.4.1 and I enabled CONFIG_MODULES, CONFIG_MODVERSIONS and CONFIG_KMOD.

Thanks,
Uros

--
Uros Prestor
[email protected]

http://www.tux.org/lkml/#s8-8

If you still get problems after that process, let me know.

It looks like `make dep' is broken if you're doing a parallel build. For example, if I do

     # make mrproper
     # cp ../.config .
     # make oldconfig
     # make dep
     # find . -name "*.ver" | xargs fgrep jiffies
     ./include/linux/modules/ksyms.ver:#define
     __ver_sysctl_jiffies  smp_1d9a67c4
     ./include/linux/modules/ksyms.ver:#define
     sysctl_jiffies        _set_ver(sysctl_jiffies)
     ./include/linux/modules/ksyms.ver:#define
     __ver_proc_dointvec_jiffies   smp_f9e749ca
     ./include/linux/modules/ksyms.ver:#define
     proc_dointvec_jiffies _set_ver(proc_dointvec_jiffies)
     ./include/linux/modules/ksyms.ver:#define
     __ver_proc_doulongvec_ms_jiffies_minmax       smp_b3cd4e88
     ./include/linux/modules/ksyms.ver:#define
     proc_doulongvec_ms_jiffies_minmax_set_ver(proc_doulongvec_ms_jiffies_minmax)

     ./include/linux/modules/ksyms.ver:#define __ver_jiffies
     smp_0da02d67
     ./include/linux/modules/ksyms.ver:#define jiffies
     _set_ver(jiffies)

On the other hand, if I do the same as above except for `make -j2 dep' I don't get any versioning info for jiffies. Looks like parallel build is broken.

Uros

--
Uros Prestor
[email protected]

Parallel make dep with modversions has been broken for a long time. The current makefiles have incorrect or missing internal dependencies. You have to workaround by

make dep clean && make -j bzImage modules

For 2.5 the makefile system is being redesigned from scratch and will be fully parallel, but 2.4 is beyond repair. Just live with serial make dep clean.