As far as I understood Module.symvers file provides list of symbols exported by modules plus license these are exported under and optionally a CRC. Other modules can depend on these symbols for their purposes and it's for sure logical that if my module depends on some module X, this module X should be at least built, because it defines symbols I need. Module.symvers thus serves as a sanity check mechanism, am I right?

I'm struggling to understand why some symbols that clearly do not depend on any modules are not being exported, e.g. I want to use debugfs_create_u32 function. It seems to me that the only dependency that should exist is CONFIG_DEBUG_FS, however enabling this option exports only fraction of symbols that #include <linux/debugfs.h> declares. Thus every time I'm trying to compile my module I get MODPOST errors regarding undefined symbols. My workaround was to find random module that actually uses debugfs_create_u32 symbol in it's code and compile kernel with it, this module doesn't define debugfs_create_u32, I do not use functionality of this module, I do not actually need it and it feels like the only useful thing this module does for me is adding line to Module.symvers file and everything starts to magically work. Similar problem I've encountered with i8253_lock symbol, I don't need pcspkr module, I just want i8253_lock, but to get it I need to compile pcspkr for some reason.

I'm pretty sure that I'm missing something crucial here, that's why I'm so confused, thus I kindly ask to explain how to make sense of the above described situation, what is the logic behind generation of Module.symvers?

1 Answer 1


I don't know if you are still struggling with this problem and I know it is a bit late, but I ran into the same problem tonight. And the culprit was the following option in the kernel configuration:



If you have the option activated, just disable it.

Hope it helps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .