ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I made a small correction that was recommended to me to the source file of one of my media modules. But, having done that, I can't seem to compile it. I get all kinds of reference errors and it's pretty clear I am doing something fundamentally wrong. I tried the Makefile that shares the directory of the source code, but that doesn't work either.
I am beginning to think that this has something to do with compiling the kernel, but do I have to recompile the whole kernel just to compile one module?
No, you don't have to compile the whole kernel when you'd like to add a module.
Write more about your problem, especially copy the errors you get and write how you compile your module.
I get over a hundred lines of errors, do you really want me to post them all?
Here is a recent development. I found a GUI tool for configuring the kernel called "Linux Kernel Configurator" where I found the module that I wanted to change and add. I look at the source code in the /build directory and it already had the changes I wanted. So, I just added the module using the Configurator. As I made the changes I was prompted to perform several 'makes'. First, 'make symlink dep' which I did and then I was prompted 'run make bzimage, make bzDisk or make install now'. I ran 'make install' having had the most familiarity with this command and the procedure is still running. I'm trying to figure out what I have done. Am I now compiling the module into the kernel? I didn't really intend to do that. What is going on?
I have managed to actually compile a module using 'make modules module_install' from the /build directory. But I am having other problems. Here is what happened when I tried to alter the driver, in this case it is the radio-cadet.c file for the media/radio drivers as indicated:
First, I went to /lib/modules/2.4.18-5/build/drivers/media/radio for the cadet-radio-c file where I made the changes I wanted to the .c file. I move further up the directory to the build directory where I run 'make modules module_install'. I find the object file in the same directory as its source code. I copy the object code to /lib/modules/2.4.18-5/kernel/drivers/media/radio/ directory after having backed up the original to one of my user's directory.
Then, I insmod the module (io=0x200), but I get a whole list of 'unresolved symbols' errors. I used to get these errors because a videodev module needs to be added before adding the radio-cadet module. But, lsmod shows that videodev is in place. Thinking that the altered code is the problem, I change it back and it makes no difference. I move the original object code back from my user's directory and it loads fine.
Yes, I would like to know more about what this Kernel Configurator is doing. It shows the radio-cadet module is now in place, but I don't see any functionality as a consequence.
Last edited by SparceMatrix; 08-24-2002 at 03:33 PM.
I have a media module that I wish to make a small alteration to. I have the source code that comes with my distribution, Red Hat 7.3. I make the alteration and recompile the modules from the /lib/modules/2.4.18-5/build directory using 'make modules' and/or 'make modules moduels_install'. When I insmod this module, I get the following unresolved symbol errors:
When I try to insmod the same precompiled module that orginally came with the distribution under the same circumstances, I get no such errors. Even more remarkeable is if I compile the source code without making any alterations to it I get the same unresolved symbols errors.
I have since upgraded my kernel, could that somehow be the problem?
Any and all tips and clues would be appreciated.
Last edited by SparceMatrix; 08-26-2002 at 03:39 AM.
I don't get it. Isn't the whole purpose of a make file to manage and automate compilation? Looking in the make manual, I don't even see a '-D' option. What is that supposed to do? I don't see anything in the Makefile in the source code directory to suggest how to run make in that directory.
Here is the Makefile in the source code directory:
Code:
#
# Makefile for the kernel character device drivers.
#
# Note! Dependencies are done automagically by 'make dep', which also
# removes any old dependencies. DON'T put your own dependencies here
# unless it's something special (ie not a .c file).
#
# Note 2! The CFLAGS definitions are now inherited from the
# parent makes..
#
# Object file lists.
obj-y :=
obj-m :=
obj-n :=
obj- :=
O_TARGET := radio.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
export-objs := miropcm20-rds-core.o
list-multi := miropcm20.o
miropcm20-objs := miropcm20-rds-core.o miropcm20-radio.o
obj-$(CONFIG_RADIO_AZTECH) += radio-aztech.o
obj-$(CONFIG_RADIO_RTRACK2) += radio-rtrack2.o
obj-$(CONFIG_RADIO_SF16FMI) += radio-sf16fmi.o
obj-$(CONFIG_RADIO_CADET) += radio-cadet.o
obj-$(CONFIG_RADIO_TYPHOON) += radio-typhoon.o
obj-$(CONFIG_RADIO_TERRATEC) += radio-terratec.o
obj-$(CONFIG_RADIO_MAXIRADIO) += radio-maxiradio.o
obj-$(CONFIG_RADIO_RTRACK) += radio-aimslab.o
obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o
obj-$(CONFIG_RADIO_MIROPCM20) += miropcm20.o
obj-$(CONFIG_RADIO_MIROPCM20_RDS) += miropcm20-rds.o
obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o
obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o
obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o
include $(TOPDIR)/Rules.make
miropcm20.o: $(miropcm20-objs)
$(LD) -r -o $@ $(miropcm20-objs)
I am completely clueless as to how interpret any of this. I suspect it is just one of a network of Makefiles. How are you supposed to tell what is going on? I have some elementary exposure to the basic functions of a Makefile and I seen none of them here.
I can't find this now, when I want to find it. For a module, you need -DMODULE, -D__KERNEL__ and -DLINUX, so compilation command is something like this:
gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -c module.c
Of course, your module may need more option. The best method is to compile your kernel modules and look which options are used with the module you'd like to compile (I know, it's quite hard...).
Originally posted by SparceMatrix
First, I went to /lib/modules/2.4.18-5/build/drivers/media/radio for the cadet-radio-c file where I made the changes I wanted to the .c file. I move further up the directory to the build directory where I run 'make modules module_install'. I find the object file in the same directory as its source code. I copy the object code to /lib/modules/2.4.18-5/kernel/drivers/media/radio/ directory after having backed up the original to one of my user's directory.
Up to here, you're good. Once the new module is in place in the /lib/mod tree, you must run "depmod" (as root) to resolve the dependencies of the new module (and to fix up the ones that depended on the old module and now depend on the new module). The file created by depmod is used by insmod to find dependencies when the module is loaded. After that, I'd say you should be ok.
Running depmod doesn't work. Actually, I took a little initiative and ran 'depmod -au' and got my 'unresolved symbols' errors before I even tried actually running the module.
I suspect there are some basic compile issues here I am missing.
I have made a little progress. Using the excellent text "Linux Programming Unleashed 2nd ed", I have begun to understand Makefiles better. Using the excellent tutorials here, http://tldp.org/LDP/lkmpg/ and here, /usr/share/doc/HOWTO/Module-HOWTO/x653.html in my downloaded LDP (Linux Documentation Project) documentation, I am trying to confront the problem at a more elementary level. There are some 'hello world' type demonstrations of creating and compiling modules and I am having some new problems:
Why won't this simple Hello World module compile?
here is the sample from my downloaded LDP documentation,
Code:
/* hello.c
*
* "Hello, world" - the loadable kernel module version.
*
* Compile this with
*
* gcc -c hello.c -Wall
*/
/* Declare what kind of code we want from the header files */
#define __KERNEL__ /* We're part of the kernel */
#define MODULE /* Not a permanent part, though. */
/* Standard headers for LKMs */
#include <linux/modversions.h>
#include <linux/module.h>
#define _LOOSE_KERNEL_NAMES
/* With some combinations of Linux and gcc, tty.h will not compile if
you don't define _LOOSE_KERNEL_NAMES. It's a bug somewhere.
*/
#include <linux/tty.h> /* console_print() interface */
/* Initialize the LKM */
int init_module()
{
console_print("Hello, world - this is the kernel speaking\n");
/* More normal is printk(), but there's less that can go wrong with
console_print(), so let's start simple.
*/
/* If we return a non zero value, it means that
* init_module failed and the LKM can't be loaded
*/
return 0;
}
/* Cleanup - undo whatever init_module did */
void cleanup_module()
{
console_print("Short is the life of an LKM\n");
}
This is compiled according to the HowTo,
Code:
gcc -c -Wall hello.c
But I get errors,
Code:
In file included from HelloMod.c:15:
/usr/include/linux/modversions.h:1:2: #error Modules should never use kernel-headers system headers,
/usr/include/linux/modversions.h:2:2: #error but rather headers from an appropriate kernel-source package.
/usr/include/linux/modversions.h:3:2: #error Change -I/usr/src/linux/include (or similar) to
/usr/include/linux/modversions.h:4:2: #error -I/lib/modules/$(uname -r)/build/include
/usr/include/linux/modversions.h:5:2: #error to build against the currently-running kernel.
I first confront the problem of the include file since I've done that before, by adding,
It compiles without problems, but when I go to 'insmod' the new module, I get the following errors,
Code:
./HelloMod.o: kernel-module version mismatch
./HelloMod.o was compiled for kernel version 2.4.18-5custom
while this kernel is version 2.4.18-5.
Now, there is a directory in the modules directory called /2.4.18-5custom, but since I specifically directed the compiler to use the other directory, it doesn't make sense that there would be a version problem.
Using the other tutorial at http://tldp.org/LDP/lkmpg/ I find another excellent hello world module demonstration that also applies a simple Makefile and highlights the application of the -D switches, which I try to apply. But, I get the same errors when I try to 'insmod' this module.
Code:
./HelloMod.o: kernel-module version mismatch
./HelloMod.o was compiled for kernel version 2.4.18-5custom
while this kernel is version 2.4.18-5.
Not only that, when I add the -D and -c switches to compile the module I first posted about, I continue to get the 'unresolved symbols' errors. But, at this point, I will be happy to get these Hello World modules operating.
Does anyone have any idea why my modules are being compiled against the wrong version? Does this have anything to do with the GUI tool I applied earlier? Can I undo it?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.