I am pretty familiar with Makefiles and kernel modules, but recently I got a problem in my Makefile that doesn't make any sense -- on using wildcards.
To demonstrate this, I am compiling a hello world kernel module from scratch.
The directory structure is like this:
hello_mod/
|
--- hello.c
|
--- Makefile
Here is the actual makefile :
CFILES := $(wildcard hello.c*)
#CFILES := hello.c
OBJS := $(CFILES:.c=.o)
KSRC := /lib/modules/$(shell uname -r)/build
obj-m += hello_world.o
hello_world-y := $(OBJS)
all:
#echo $(CFILES)
$(MAKE) -C $(KSRC) M=$$PWD modules
clean:
$(MAKE) -C $(KSRC) M=$$PWD clean
.PHONY: clean
The problem is that even though the commented $(CFILES) and the uncommented $(CFILES) are exactly the same, the build fails on using the first $(CFILES) with the following error:
*** No rule to make target `/home/test/hello_mod/hello_world.c', needed by
/home/test/hello_mod/hello_world.o'. Stop.
If the commented $(CFILES) is used, it works perfectly.
If someone wants to test this out, I'm including the source for the hello world source which is hello.c :
#include <linux/kernel.h>
#include <linux/module.h>
static int mod_init()
{
printk("Hello\n");
return 0;
}
static void mod_exit()
{
printk("Bye world\n");
}
module_init(mod_init);
module_exit(mod_exit);
Does anyone know why it is behaving as such? And I need to use wildcards in the makefile. Any help will be appreciated.
There are two makes happening here. The first really only relies on the KSRC variable and the recursive make call. The second make only needs the CFILES, OBJS, obj-m, and hello_world-y variables, and doesn't make use of the all: target. So your debug is showing that CFILES is set correctly for the first Make, where it's not being used, and is not showing it in the second make, where it is.
You're wildcard expanding from a different directory, and not picking up the right files. Try this for CFILES:
CFILES := $(notdir $(wildcard $M/hello.c*))
SRCDIRS := subdir1 subdir2
CFILES := $(strip $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c)))
should probably be (see foreach example in documentation)
SRCDIRS := subdir1 subdir2
CFILES := $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c))
(no need to $(strip), .... or perhaps
CFILES := $(wildcard {subdir1,subdir2}/*.c)
Use remake, probably as remake -x, to debug such issues.
Related
For a lpc3250 board, we had to developer a Linux kernel module to control the PWM output. I've created a 'helper' module which contains methodes like PMW1_ENABLE which set the correct bit at 1.
Unfortunately I run into problems when I create multiple .c and .h files. When I put all the code in just 1 file, the solution works fine. When I split it nicely in additional .c and .h files, something weird is happening. Even just printk statements do not show up on the console.
Most weird part, during cross compiling, no errors are shown so it looks like the binary is ok but it isn't.
Does this sound familiair? Could it be an issue with my makefile?
ARCH := arm
CROSS_COMPILE := /usr/local/xtools/arm-unknown-linux-uclibcgnueabi/bin/arm-linux-
CC= $(CROSS_COMPILE)gcc
obj-m := pwmdriver.o
pwmdriver-objs := pwmhelper.o pwmdriver.o
KDIR := /home/student/felabs/sysdev/tinysystem/linux-2.6.34
WORKINGDIRFIXED := /home/student/PRT/5_AssigPWM
export
all:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) modules
clean:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) clean
I organized the kernel modules as different sub-component, so I can easily insert/remove existing sub-module to try or integrating stuff.
The directory layout is shown as below:
foo --+-- Makefile
|
+-- main.c
|
+-- include --+-- foo1.h
| |
| +-- ... (other headers)
|
|
+-- src ------+-- foo1.c
|
+-- ... (other sources)
Here's my Makefile,
MODULE_NAME = foo
obj-m += $(MODULE_NAME).o
# [approach 1-1]
# SRCS := main.c src/foo1.c
# [approach 1-2]
SRCS := main.c $(wildcard src/*.c)
$(MODULE_NAME)-objs += main.o $(SRCS:.c=.o)
all:
# [2] echo to check if foo-objs values changes
echo $($(MODULE_NAME)-objs)
KCFLAGS="-I$(PWD)/include" \
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I got warning shown as below when I tried to replace approach [1-1] with [1-2] in my Makefile above.
WARNING: "InitFoo1" [.../foo/foo.ko] undefined!
WARNING: "CleanuptFoo1" [.../foo/foo.ko] undefined!
From the console output, I don't see the src/foo1.c got compiled as if I am using approach [1-1] in Makefile.
# [2] echo to check if foo-objs values changes
echo main.o main.o src/foo1.o
main.o main.o src/foo1.o
KCFLAGS="-I/home/cyng93/experiment/issues/so_kbuild_wildcard/include" \
make -C /lib/modules/4.4.23-PT-ProbeOn-AuditOn+/build M=/home/cyng93/experiment/issues/so_kbuild_wildcard modules
make[1]: Entering directory '/linux'
CC [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/main.o
LD [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "InitFoo1" [/home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko] undefined!
WARNING: "CleanupFoo1" [/home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko] undefined!
CC /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.mod.o
LD [M] /home/cyng93/experiment/issues/so_kbuild_wildcard/foo.ko
make[1]: Leaving directory '/linux'
I try to echo foo-objs(check [2] in Makefile) and found out that the value are the same for both approach [1-1] & [1-2].
Does anyone on SO has came up with similar issues can help to shade some light on ?
(I prefer [1-2] because it can save my effort from updating the Makefile when new sub-component is added)
Below I also attached the source code of main.c, foo1.c & foo1.h.
You can also check the github repo for this issue for easier access to those code.
main.c
#include <linux/module.h>
#include "foo1.h"
static int myinit(void)
{
printk("Module inserted!\n");
InitFoo1();
return 0;
}
static void myexit(void)
{
CleanupFoo1();
printk("Module removed!\n");
}
module_init(myinit);
module_exit(myexit);
MODULE_LICENSE("GPL v2");
Here, foo1 is a sub-component, where simply print out some stuff during its intialization and cleanup:
./include/foo1.h
#ifndef FOO1_H
#define FOO1_H
int InitFoo1(void);
void CleanupFoo1(void);
#endif
./src/foo1.c
#include <linux/module.h>
#include "foo1.h"
int InitFoo1(void)
{
printk("Init Foo1\n");
return 0;
}
void CleanupTest(void)
{
printk("Cleanup Foo1\n");
}
update_2018/01/15
According to Tsyvarev answer below, one can correct the Makefile by modifying Makefile as below:
MODULE_NAME = foo
obj-m += $(MODULE_NAME).o
# [approach 1-1]
# SRCS := main.c src/foo1.c
# [approach 1-2 (not working)]
# SRCS := main.c $(wildcard src/*.c)
# [approach 1-2 (working)]
MISC := $($(src)/wildcard src/*.c)
SRCS := main.c $(MISC:$(src)%/=%)
$(MODULE_NAME)-objs += main.o $(SRCS:.c=.o)
all:
# [2] echo to check if foo-objs values changes
echo $($(MODULE_NAME)-objs)
KCFLAGS="-I$(PWD)/include" \
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
When build the kernel module your Makefile is processed twice:
When you type make from your module's directory.
Inside Kbuild process, because you pass M=$(PWD) option to it.
First time the Makefile is processed with current directory equal to the module's directory. So wildcard works as expected, which is confirmed by printing from all receipt.
But the second time the Makefile is processed with current directory equal to kernel's build directory (/lib/modules/4.4.23-PT-ProbeOn-AuditOn+/build in your case). In that mode
$(wildcard src/*.c)
attempts to find a file in kernel's build directory, which obviously fails.
At the time of second processing one may refer to module's build directory with $(src).
Such way one may use wildcard() for collect module's sources. But note, that Kernel build system expects path to source file (more precisely, to object file) to be relative to module's build directory. So, one need to strip $(src) component of every file obtained with wildcard().
sorry if this is noob question.
In my c function, I use a macro defined in btrfs_inode.h file.
When I include the file directly to path:
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h"
the project compiles with no errors, I dont want to use that direct path, I download the package kernel-source that contains this header file.
The location of the header file after installing the package is at: /usr/src/linux/fs/btrfs/
So I change the #include to :
#include "btrfs_inode.h"
and i wish to add "/usr/src/linux/fs/btrfs/" as a location that it will search for "btrfs_inode.h" and get: "/usr/src/linux/fs/btrfs/btrfs_inode.h"
I get error:
/bin/sh: 1: /usr/src/linux/fs/btrfs/: Permission denied
I am running make as root.
Makefile:
all:: user
obj-m += my-driver.o
# Make arguments
PWD := $(shell pwd)
INCLUDE := -I/usr/include/asm/mach-default/
KDIR := /lib/modules/$(KERNEL_HEADERS)/build;/usr/src/linux/fs/btrfs/
# Add flags to auto build
EXTRA_CFLAGS +=-D__Linux -std=gnu99
# extra warning flags
ccflags-y := -Wall -Wextra #-pedantic
# disable some warning flags
ccflags-y += -Wno-unused-parameter
# make all warnings into errors
ccflags-y += -Werror
# increase verbosity
KBUILD_VERBOSE := 1
all::
$(MAKE) -C $(KDIR) $(INCLUDE) SUBDIRS=$(PWD) modules
So first off, avoid making as root when possible. Next, you added your directory to KDIR, not to INCLUDE (and then you pass KDIR to the -C argument of make, so you would have a line that looks like:
make -C /lib/modules/$(KERNEL_HEADERS)/build;/usr/src/linux/fs/btrfs/ ...
Notice the semicolon, which bash will interperet as the end of a command, and beginning of the next command. So it tries to run make, and then tries to run /usr/src/linux/fs/btrfs/, and gives you your warning. What you should have is something like:
# Make arguments
PWD := $(shell pwd)
INCLUDE := -I/usr/include/asm/mach-default/
INCLUDE += -I/usr/src/linux/fs/btrfs/
KDIR := /lib/modules/$(KERNEL_HEADERS)/build
(you want a -I in front of the path to tell make to search for include files in that directory).
EDIT
You are also not passing the -I to your $(CC) or $(CXX) commands. To do this, you have a couple of options, though I'll suggest the least error prone one: First of all, you have to pass the flags to the sub make. To do this, first add the line:
export INCLUDE
to your main makefile. Your submake now has access to the variable $(INCLUDE). From there, if you have an explicit rule to compile the CC files, you can add $(INCLUDE) to the compile command. Something like
%.o: %.c
$(CC) $(CFLAGS) $(INCLUDE) -o $# $<
or, if you are using the built-in implicit rules, simply add $(INCLUDE) to CPP_FLAGS:
CPP_FLAGS += $(INCLUDE)
(note, CPP_FLAGS are used by default for both c and c++ compilation).
Finally, do not pass $(INCLUDE) to your make command. If you do, it tells make to look look for sub-makefiles in those directories (not gcc...).
From what I could understand via this question, you can add multiple -I flags to your Makefile.
I would like to compile a simple character device module depending on a custom header. The folder is thus organized,
+ mymod.c
| customized-header.h
| customized-header.c
| Makefile
In mymod.c, the header is thus used,
#include "customized-header.h"
In Makefile:
obj-m := mymod.o
mymod-objs := customized-header.o
KVERSION = $(shell uname -r)
PWD = $(shell pwd)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
Everything should work fine, the module gets compiled without problem, I can load the module through sudo insmod, but the module doesn't work properly. When I checked nm mymod.ko, there are a lot of vars and functions are missing. It looks as if it stopped after linking customized_header.o. If I remove this header and its function, say no header function calls from the module, it compiles perfectly with desired result.
Could you see what went wrong here?
The problem resides in the Makefile. Due to the link here, I changed it into
obj-m: mymodko.o
mymodko-obj: customized-header.o mymod.o
It now works fine. So the question was the naming of module object. We need to specify different names as in this case mymodko.o and mymod.o.
I have a main kernel module with which other kernel modules communicate. I have structured the modules like this (conceptually):
main module/
|
\drivers/
|
|\driver1
|\driver2
\driver3
Since these are kernel modules, I need to compile them like this:
make -C /lib/modules/$(shell uname -r)/build M=$(shell pwd) modules
However, since the Makefile of drivers can be called from previous directories, I need to do the $(shell pwd) before calling the other make (linux's make). So the Makefile now looks like this:
CURRENT_DIR := $(shell pwd)
.PHONY: all
all:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(CURRENT_DIR) modules
So far it is fine and it works perfectly. The problem is this: I have a file that the drivers need to include, so I have to give the include path to make. I first tried
EXTRA_CFLAGS += -I../..
and immediately understood why it doesn't work (relative path would be to /lib/module/... not to current directory). So I changed it to:
MAIN_MODULE_HOME := $(CURRENT_DIR)/../..
EXTRA_CFLAGS += -I$(MAIN_MODULE_HOME)
Oddly enough, this doesn't work! If I write
EXTRA_CFLAGS += -Ipath/I/get/from/pwd/../..
manually, it compiles! Can someone explain what I am doing wrong? Before calling make, I echoed $(CURRENT_DIR) and $(MAIN_MODULE_HOME) and the variables are meaningful.
I know that EXTRA_CFLAGS is not immediately evaluated, but since CURRENT_DIR and MAIN_MODULE_HOME are declared with := I don't understand how things are getting messed up.
(If anyone can phrase the question title better, please do!)
You should pass EXTRA_CFLAGS to make like this:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(CURRENT_DIR) \
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
Update:
The content of driver1/Makefile is read twice: first - when you run make inside driver1 directory, second - by Kbuild system.
First, CURRENT_DIR := $(shell pwd) is evaluated to something like /home/users/.../main module/drivers/driver1. Second, Kbuild evaluates CURRENT_DIR := $(shell pwd) to something like /usr/src/linux-headers-2.6.32-33-generic/
That situation described in LDD3, ch2, p24
The trick is to write your makefile as follows:
# If KERNELRELEASE is defined, we've been invoked from the
# kernel build system and can use its language.
ifneq ($(KERNELRELEASE),)
obj-m := hello.o
# Otherwise we were called directly from the command
# line; invoke the kernel build system.
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
#endif
It most likely because of recursive flavor of EXTRA_CFLAGS, which gets actually expanded in a sub-make, which doesn't have an access to MAIN_MODULE_HOME referred from it.
First, try to export MAIN_MODULE_HOME:
export MAIN_MODULE_HOME
I would also tried to flatten EXTRA_CFLAGS before using it (however, I'm not sure whether this is a good practice for Kbuild):
EXTRA_CFLAGS := $(EXTRA_CFLAGS)