Tag Archives: make

Linux Kernel Module Build Flags

Leave a reply

Building out-of-tree Linux kernel modules is pretty easy. The page https://www.kernel.org/doc/html/latest/kbuild/modules.html shows some basic info. There are some great ways to tinker with the CFLAGS (and other build flags).

The kernel module build uses rules/macros in the linux/scripts/Makefile.lib. 

# deprecated old-style kernel build flags
EXTRA_CFLAGS+=-DEXTRA_CFLAGS

The kernel best practice to set build flags is through the ccflags variable.

# these flags added to all C compiles
ccflags-y += -Wall -Werror

File-specific flags can also be set.

# Set DEBUG flag when compiling hello.c
CFLAGS_hello.o += -DDEBUG

A useful feature is also removing flags. I’m currently working with a set of vendor code that has a warning triggered by a newer version of GCC. The compile is failing because the vendor makefiles use -Werror. I can’t modify the code due to license restrictions but I can modify the makefile.

# turn off the -Werror flag
ccflags-remove-y += -Werror

Similarly, can remove flags for a specific file.

# turn off -Werror just for hello.c
CFLAGS_REMOVE_hello.o += -Werror

I Like Make.

Leave a reply

With apologies to Tom T Hall. https://www.youtube.com/watch?v=8HkiMkGp_Jo
https://www.musixmatch.com/lyrics/Tom-T-Hall/I-Like-Beer

In some of my posts I have casually mentioned
The fact that I like to write Make.
This little post is more to the point
Roll out the manual and lend me your ears

I like Make. It makes me a jolly good fellow
I like Make. It helps me unwind
And sometimes it makes me feel mellow
(all) (Makes him feel mellow)

C++’s too rough, Java costs too much
Rust puts my mouth in gear.
This little refrain should help me explain
As a matter of fact I like Make
(all) (he likes Make)

My boss stands mum when we’re having a scrum
And I’m building rules on the fly
She’s writing CMake and thinks I’m a flake
When I yell as devops goes by

I like Make. It makes me a jolly good fellow
I like Make. It helps me unwind
And sometimes it makes me feel mellow
(all) (Makes him feel mellow)

C++’s too rough, Java costs too much
Rust puts my mouth in gear.
This little refrain should help me explain
As a matter of fact I like Make
(all) (he likes Make)

Last night I dreamed and would not awake.
And I went to a place so swell
Oh, the build was clear and written with make
Then they turned it all into shell
(all) (aw)

I like Make. It makes me a jolly good fellow
I like Make. It helps me unwind
And sometimes it makes me feel mellow
(all) (Makes him feel mellow)

C++’s too rough, Java costs too much
Rust puts my mouth in gear.
This little refrain should help me explain
As a matter of fact I like Make
(all) (he likes Make)

Debugging an OpenSSL Version Problem.

Leave a reply

I’m working in a system using an older version of OpenSSL. The system builds both a cross compiled version of Python and the same version of Python built for the host. Having the same version of python both in the embedded host and the local host allows me to run the Python scripts locally on the same exact same version of Python. I can test my Python scripts locally without having to push them to the remote firmware, which is slow and expensive.

Python uses OpenSSL. The embedded Python build used a local repo copy of the 1.0.x series OpenSSL. Consequently, the host Python build also needs to use the same older 1.0.x series OpenSSL. But the host Python build used the system (default) installed dev version of OpenSSL. I would have had to remove the current version of OpenSSL and install the older version. I was troubled by that requirement.

I built the OpenSSL 1.0.x, installed it to a $HOME tree. I then had to do the hard part of aiming the system’s host Python build at the older version. Seemed simple enough: find where CFLAGS and LDFLAGS was defined, change those to aim at my local OpenSSL.

CFLAGS+=$(HOME)/include/openssl

LDFLAGS+=$(HOME)/lib

But it wasn’t working. I knew it wasn’t working because the Python link would report not being able to find the newer OpenSSL symbol names so I knew the build was still using the newer version of header files.

I needed to debug my changes to the build. Along the way, I found some useful GCC options.

Debugging a header file include problem is straightforward: sabotage the build. I added “#error foo” to the host’s /usr/include/openssl/rsa.h and “#error bar” to the old openssl/rsa.h   Fun “make -B Modules/_ssl.o” and see which include file was being hit.  (The -B flag to make forces Make to rebuild the file regardless of timestamp.)  The build would fail with “error foo”. I was still getting the system header. I needed to see where GCC was finding its header files.

https://stackoverflow.com/questions/344317/where-does-gcc-look-for-c-and-c-header-files

specifically https://stackoverflow.com/a/41718748/39766

The set of paths where the compiler looks for the header files can be checked by the command:-

cpp -v

I added the ‘-v’ flag to the build, asking GCC to pass it along to the preprocessor.

gcc -Xpreprocessor -v $(CFLAGS) -c [etcetera]

Output looks like:

#include "..." search starts here:
#include <...> search starts here:
/home/dpoole/include/openssl
...
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.

Oops. First include should have been /home/dpoole/include not /home/dpoole/include/openssl   Fixed my CFLAGS and I’m now building Python against my local copy of openssl.

Python crashes on startup but progress!