Why the success of SCons build depends on variant_dir name? - fortran

I am bored to death with such behavior. So in SConstruct file we have the last string like this one:
import compilers, os
env = Environment(ENV = os.environ, TOOLS = ['default'])
def set_compiler(compiler_name):
env.Replace(FORTRAN = compiler_name)
env.Replace(F77 = compiler_name)
env.Replace(F90 = compiler_name)
env.Replace(F95 = compiler_name)
def set_flags(flags):
env.Replace(FORTRANFLAGS = flags)
env.Replace(F77FLAGS = flags)
env.Replace(F90FLAGS = flags)
env.Replace(F95FLAGS = flags)
mod_dir_prefix = {
"gfortran": "-J ",
"ifort": "-???",
"pgfortran": "-module "
}
flags = {
("gfortran", "debug"): "-O0 -g -Wall -Wextra -pedantic -fimplicit-none -fbounds-check -fbacktrace",
("gfortran", "release"): "-O3",
("pgfortran", "debug"): "-O0 -g -C -traceback",
("pgfortran", "release"): "-O4"
}
if not GetOption('clean'):
print "\nAvailable Fortran compilers:\n"
for k, v in compilers.compilers_dict().iteritems():
print "%10s : %s" % (k, v)
compiler = raw_input("\nChoose compiler: ")
set_compiler(compiler)
debug_or_release = raw_input("\nDebug or release: ")
set_flags(flags[(compiler, debug_or_release)])
env.Replace(FORTRANMODDIRPREFIX = mod_dir_prefix[compiler])
env.Replace(LINK = compiler)
env.Replace(LINKCOM = "$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS $_LIBFLAGS $_FRAMEWORKPATH $_FRAMEWORKS $FRAMEWORKSFLAGS")
env.Replace(LINKFLAGS = "")
env.Replace(FORTRANMODDIR = '#Mod')
Export('env')
SConscript('Sources/SConscript', variant_dir='Build', duplicate=0)
compilers.py is my own module to find some Fortran compilers which are available.
In Sources folder we have a couple of Fortran source files.
Sources\SConscript
Import('env')
env.Program('app', Glob('*.f90'))
Scons supports Fortran and everything works fine.
gfortran -o Temp\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Temp\math.o -c -O3 -JMod Sources\math.f90
gfortran -o Temp\sorts.o -c -O3 -JMod Sources\sorts.f90
gfortran -o Temp\utils.o -c -O3 -JMod Sources\utils.f90
gfortran -o Temp\main.o -c -O3 -JMod Sources\main.f90
gfortran -o Temp\app.exe Temp\kinds.o Temp\main.o Temp\math.o Temp\sorts.o Temp\utils.o
scons: done building targets.
After renaming variant_dir name to let say #Bin or #Build we get error message:
gfortran -o Bin\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Bin\main.o -c -O3 -JMod Sources\main.f90
Sources\main.f90:3.11:
USE sorts
1
Fatal Error: Can't open module file 'sorts.mod' for reading at (1): No such file or directory
Of course the order of compilation matters. But why it depends on variant_dir name? Seems like a bug, but maybe I'm doing something wrong.
P.S. This behavior doesn't depend on duplicate variable value.
P.P.S. Tested with SCons 2.0.1 on Windows with Python 2.7 and Mac OS X with Python 2.5.1.

This is a reply to an old thread, but I had virtually the same problem and needed to dig around for a solution.
Firstly, your build order is probably off because the dependency scanner for Fortran does not work properly. Try running
scons [your_arguments] -n --tree=all | less
which won't actually compile anything but show you the commands and in the end will print the dependency tree as Scons sees it.
A possible solution:
Try adding the line (I added your source for context):
env.Replace(FORTRANMODDIR = '#Mod')
env.Replace(FORTRANPATH = '.' ]
Export('env')
As far as I understand, paths are relative to the "virtual" location of the SConscript file (i.e. the src directory or the variant build directory), this should add the directory containing the source files to the scanner's search path.
In my version of scons (2.3.0), I cannot use the duplicate=0 argument, since it automatically inserts the original source directory into the module path, causing the command line to look like -module build/ -module src/ (ifort) and essentially overriding my preference not to clutter the source directory. This might be a bug, though.

Related

Cross compiling cppzmq for arm cannot find sodium.h

I have a C++ application and I need to cross compile it for armv7. It needs 3 libraries:
cppzmq
Eigen
nlohmann/json
What I have
A raspberry compute module 3+ with Debian 9 Buster
Manjaro Linux (or windows I guess)
$ uname -a
Linux user 5.15.71-1-MANJARO #1 SMP PREEMPT Wed Sep 28 11:24:27 UTC 2022 x86_64 GNU/Linux
A project set up with CLion and Meson by me following the basic cross compiling tutorial (see below for files content)
arm-none-linux-gnueabihf toolchain
meson txt file for setting up the toolchain
meson.build file
meson .wrap files for easier dependencies management
What is my issue
This is my first time doing cross compiling or working with C in general, I know I'm really near the solution but I'm wasting a little too much time on this.
I'm able to compile Eigen and Json
I added catch2 and libzmq to solve some issues and I can compile these too
libobsd and libsodium are compiled but not picked up by cppzmq
I think I need to pass the compiled libobsd and libsodium as libraries to cppzmq but I'm not sure. Error log cleaned up:
Executing subproject cppzmq
cppzmq| Project name: cppzmq
cppzmq| Project version: 4.8.1
cppzmq| C++ compiler for the host machine: /usr/bin/arm-none-linux-gnueabihf-g++ (gcc 10.3.1 "arm-none-linux-gnueabihf-g++ (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621")
cppzmq| C++ linker for the host machine: /usr/bin/arm-none-linux-gnueabihf-g++ ld.bfd 10.3-2021
cppzmq| C++ compiler for the build machine: c++ (gcc 12.2.0 "c++ (GCC) 12.2.0")
cppzmq| C++ linker for the build machine: c++ ld.bfd 2.39.0
cppzmq| Dependency libzmq from subproject subprojects/zeromq-4.3.4 found: YES undefined
cppzmq| Dependency threads found: YES unknown (cached)
cppzmq| Dependency catch2 from subproject subprojects/Catch2-3.1.0 found: YES 3.1.0
cppzmq| Build targets in project: 149
cppzmq| Subproject cppzmq finished.
meson 0.0.1
Subprojects
catch2 : YES
cppzmq : YES
eigen : YES
json : YES
libobsd : YES
libzmq : YES 2 warnings
User defined options
Cross files: /my_path/meson/raspberry-cm3+.txt
backend : ninja
Found ninja-1.11.1 at /usr/bin/ninja
Cleaning... 107 files.
[1/270] Compiling C++ object subprojects/zeromq-4.3.4/libobjects.a.p/src_msg.cpp.o
FAILED: subprojects/zeromq-4.3.4/libobjects.a.p/src_msg.cpp.o
/usr/bin/arm-none-linux-gnueabihf-g++ -Isubprojects/zeromq-4.3.4/libobjects.a.p -Isubprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4/include -Isubprojects/zeromq-4.3.4/__CMake_build -I../srcdir/subprojects/zeromq-4.3.4/__CMake_build -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O0 -g -fPIC -Wno-tautological-constant-compare -O3 -DNDEBUG -DZMQ_CUSTOM_PLATFORM_HPP -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -MD -MQ subprojects/zeromq-4.3.4/libobjects.a.p/src_msg.cpp.o -MF subprojects/zeromq-4.3.4/libobjects.a.p/src_msg.cpp.o.d -o subprojects/zeromq-4.3.4/libobjects.a.p/src_msg.cpp.o -c ../srcdir/subprojects/zeromq-4.3.4/src/msg.cpp
In file included from ../srcdir/subprojects/zeromq-4.3.4/src/msg.cpp:31:
../srcdir/subprojects/zeromq-4.3.4/src/compat.hpp:42:10: fatal error: bsd/string.h: No such file or directory
42 | #include <bsd/string.h>
| ^~~~~~~~~~~~~~
compilation terminated.
[2/270] Compiling C++ object subprojects/zeromq-4.3.4/libobjects.a.p/src_ipc_address.cpp.o
FAILED: subprojects/zeromq-4.3.4/libobjects.a.p/src_ipc_address.cpp.o
/usr/bin/arm-none-linux-gnueabihf-g++ -Isubprojects/zeromq-4.3.4/libobjects.a.p -Isubprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4/include -Isubprojects/zeromq-4.3.4/__CMake_build -I../srcdir/subprojects/zeromq-4.3.4/__CMake_build -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O0 -g -fPIC -Wno-tautological-constant-compare -O3 -DNDEBUG -DZMQ_CUSTOM_PLATFORM_HPP -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -MD -MQ subprojects/zeromq-4.3.4/libobjects.a.p/src_ipc_address.cpp.o -MF subprojects/zeromq-4.3.4/libobjects.a.p/src_ipc_address.cpp.o.d -o subprojects/zeromq-4.3.4/libobjects.a.p/src_ipc_address.cpp.o -c ../srcdir/subprojects/zeromq-4.3.4/src/ipc_address.cpp
In file included from ../srcdir/subprojects/zeromq-4.3.4/src/ipc_address.cpp:31:
../srcdir/subprojects/zeromq-4.3.4/src/compat.hpp:42:10: fatal error: bsd/string.h: No such file or directory
42 | #include <bsd/string.h>
| ^~~~~~~~~~~~~~
compilation terminated.
[3/270] Compiling C++ object subprojects/zeromq-4.3.4/libobjects.a.p/src_curve_mechanism_base.cpp.o
FAILED: subprojects/zeromq-4.3.4/libobjects.a.p/src_curve_mechanism_base.cpp.o
/usr/bin/arm-none-linux-gnueabihf-g++ -Isubprojects/zeromq-4.3.4/libobjects.a.p -Isubprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4 -I../srcdir/subprojects/zeromq-4.3.4/include -Isubprojects/zeromq-4.3.4/__CMake_build -I../srcdir/subprojects/zeromq-4.3.4/__CMake_build -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O0 -g -fPIC -Wno-tautological-constant-compare -O3 -DNDEBUG -DZMQ_CUSTOM_PLATFORM_HPP -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -MD -MQ subprojects/zeromq-4.3.4/libobjects.a.p/src_curve_mechanism_base.cpp.o -MF subprojects/zeromq-4.3.4/libobjects.a.p/src_curve_mechanism_base.cpp.o.d -o subprojects/zeromq-4.3.4/libobjects.a.p/src_curve_mechanism_base.cpp.o -c ../srcdir/subprojects/zeromq-4.3.4/src/curve_mechanism_base.cpp
In file included from ../srcdir/subprojects/zeromq-4.3.4/src/curve_mechanism_base.cpp:32:
../srcdir/subprojects/zeromq-4.3.4/src/curve_mechanism_base.hpp:38:10: fatal error: sodium.h: No such file or directory
38 | #include "sodium.h"
| ^~~~~~~~~~
compilation terminated.
Files Details
raspberry-cm3+.txt to set up the cross compiling
[binaries]
c = '/usr/bin/arm-none-linux-gnueabihf-gcc'
cpp = '/usr/bin/arm-none-linux-gnueabihf-g++'
ar = '/usr/bin/arm-none-linux-gnueabihf-ar'
strip = '/usr/bin/arm-none-linux-gnueabihf-strip'
[host_machine]
system = 'linux'
cpu_family = 'arm'
cpu = 'armv7hl'
endian = 'little'
meson.build to set up the project
project('meson', 'cpp', version : '0.0.1')
cpp = meson.get_compiler('cpp')
os = target_machine.system()
cmake = import('cmake')
dep_eigen = subproject('eigen').get_variable('eigen_dep')
lib_zmq = cmake.subproject('libzmq')
dep_zmq = lib_zmq.dependency ('libzmq')
# lib_libsodium = cmake.subproject('libsodium')
# dep_libsodium = lib_libsodium.dependency ('sodium')
# lib_libsodium = cpp.find_library('libsodium', required: false)
# if lib_libsodium.found()
# dep_sqlitecpp = lib_libsodium
# endif
dep_catch = subproject('catch2').get_variable('catch2_dep')
dep_libobsd = subproject('libobsd').get_variable('libobsd_dep')
if cpp.has_header('zmq.hpp')
# cppzmq is a header-only dependency, so if we already have the
# header in place, we don't need to actually change anything
dep_cppzmq = [] #declare_dependency()
else
dep_cppzmq = subproject('cppzmq').get_variable('cppzmq_dep')
endif
if cpp.has_header('nlohmann/json.hpp')
dep_json = [] #declare_dependency()
else
dep_json = subproject('json').get_variable('nlohmann_json_dep')
endif
deps = [
dep_eigen,
# dep_libsodium,
dep_libobsd,
dep_catch,
dep_zmq,
dep_cppzmq,
dep_json
]
executable(
'demo',
'main.cpp',
dependencies :deps
)
Wrap Files
catch2, cppzmq, eigen, libobsd and json are the default ones from the meson wrap repository
libsodium.wrap (custom repo to use cmake)
[wrap-git]
directory = libsodium-1.0.18
url = https://github.com/robinlinden/libsodium-cmake.git
revision = master
depth = 1
clone-recursive = true
[provide]
libsodium = libsodium_dep
sodium = sodium_dep
libzmq.wrap
[wrap-file]
directory = zeromq-4.3.4
source_url = https://github.com/zeromq/libzmq/releases/download/v4.3.4/zeromq-4.3.4.tar.gz
source_filename = zeromq-4.3.4.tar.gz
source_hash = c593001a89f5a85dd2ddf564805deb860e02471171b3f204944857336295c3e5
[provide]
libzmq = libzmq_dep
Notes
I don't mind switching build tools to CMake for example
there is another toolchain on the AUR repository I don't know if it could change anything (trying right now)
???
profit

g++ does not produce debug symbols

I am learning linux, and my first step is to adapt my project for running on linux. Here is simple makefile (in educational purposes mostly), which generates out file:
#------------------------BUILD VARIABLES-----------------------------
# Directories, containing headers
INCLUDE_DIR = ../Include/
# Output directory which will contain output compiled file
OUTPUT_DIR = ../Bin/Debug/
SOURCES = EngineManager.cpp Geometry.cpp Main.cpp Model.cpp \
Shaders.cpp TGAImage.cpp
HEADERS = EngineManager.h Geometry.h Line.h Model.h Shaders.h \
TGAImage.h Triangle.h
#------------------------BUILD_RULES---------------------------------
TinyRenderBuilding : $(addprefix $(INCLUDE_DIR), $(HEADERS)) $(SOURCES)
mkdir -p $(OUTPUT_DIR)
g++ -std=c++14 -o $(OUTPUT_DIR)TinyRender.out -g -I$(INCLUDE_DIR) $(SOURCES)
I cannot understand, why does g++ not generate debug symbols? -g option is presented
To include debug symbols when compiling with g++ you need to pass the -g option.
In a make make file this usually means adding it to to CXXFLAGS.
Also make sure you pass the -g option when you create the executable: when you compile you turn .cpp files into .o files, when you do the linking you turn those .o files into your executable).
If you change the options before running make again be sure to run a make clean cause otherwise it won't get recompiled.
Finally, make sure that you do not have additional steps like strips command run on the executable (which would remove debugging symbols).
you can use
objdump --syms <executable-file>
to check if an executable have symbols.
when it doesn't have symbols it will say something like:
SYMBOL TABLE:
no symbols
(I'm no experto of C / C++ programming, I just run into this while I was trying to debug someone else code)
According to your makefile g++ should produce debug symbols (-g option is presented). To confirm this you can run file on resulting binary:
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9fe588c18099ef418daf288931bb033cc287922e, with debug_info, not stripped
(Note with debug_info string in output)
I'm not entirely sure, but you can try -g or -ggdb.You can do some research on these. We were using these parameters to debug the C program with the gdb tool.

Scons: how to check file before compilation with commands which doesn't product any output file?

I work with project in which every object files is being built 3 times:
With newest g++ with lots of flags in order to find every possible errors and warnings
With clang in order to do as above and check style.
With g++ compatible with 3rdpart libraries (no newer version, but entire product is based of the libraries)
It works that way: if any object file should be recompiled: the steps 1, if success then 2, if success then 3 is being done. It is done with makefile, but I'm planning to use scons to do its. The problem is that in current solution object file from 1 and 2 is being saved into /dev/null.
I've tried something line this:
3 files in the same directory: hello.cc, Sconstruct, Sconscript
SConstruct
#!python
warningFlags = ' -Wall -Wextra -Werror' # and many more
env = Environment(CXX = 'g++-4.8', parse_flags = warningFlags, CPPPATH = '.')
builtObjects = env.SConscript('SConscript', variant_dir='built', duplicate=0, exports='env')
env.Program(target = 'hello', source = builtObjects)
SConscript
#!python
Import('env')
builtObjects = env.Object(source = 'hello.cc')
checkWithClang = env.Command('/dev/null', builtObjects, 'clang -o $TARGET -Wall -Werror')
env.Depends(checkWithClang, builtObjects)
Return('builtObjects')
The output from scons is:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: built
g++-4.8 -o built/hello.o -c -Wall -Wextra -Werror -Ibuilt -I. hello.cc
g++-4.8 -o hello built/hello.o
scons: done building targets.
EDIT:
Is it possible to somehow check in scons:
if object file should be rebuilt?
Pseudo code:
src = 'hello.cc'
if shouldObjectFileBeRebuilt(src):
checkWithClang = env.Command('/dev/null', builtObjects, 'clang -o $TARGET -Wall -Werror')
builtObjects = env.Object(source = src)
env.Depends(checkWithClang, builtObjects)
try
src = "hello.cc"
builtObjects = env.Object(source = src)
checkWithClang = env.Command('/dev/null', src, 'clang -o $TARGET -Wall -Werror')
env.Depends(builtObjects, checkWithClang)
buildobjects represent '.o' files, so you should put '.c' files to clang
you want buildObjects to be built after clang objects - change the order
Still - building into /dev/null will probably break dependency tree, you might consider something like:
checkWithClang = env.Object(source = src, CC="clang", OBJPREFIX="clang-")
this will build all .c files with clang and store extra .o files, allowing scons to rebuild only what is necessarry

Scons - build order of Fortran files

Building modules in Fortran needs to be done in a specific order, e.g. if a file A.f needs module defined in B.f, then B.f needs to be compiled first. How can I impose such build order in Scons? If I provide it with a list of source files, it arranges them alphabetically (so A.f is compiled before B.f). I read about Requires() and Depends() functions, but wasn't able to get them to work for me.
I would be happy with just listing source files in order I need them compiled (so disabling reshuffling them in alphabetical order), but any other method would be welcomed as well.
As per Kyle's request, here's my Sconscript and a build log:
# Main program building script
Import('env')
PROGRAM = 'main.exe'
SRC_PREFIX = './src/'
SRC = [ 'array_1D_module.f',
'array_2D_module.f',
'array_3D_module.f',
'thomas_algorithm_module.f',
'histogram_module.f',
'histogram_computer_module.f',
'density_parameters_module.f',
'diffusion3D_aos_z_sub_solver_module.f',
'diffusion3D_aos_y_sub_solver_module.f',
'diffusion3D_aos_x_sub_solver_module.f',
'diffusion3D_aos_solver_module.f',
'nonlinear_diffusion_utilities_module.f',
'nonlinear_diffusion_parameters_module.f',
'derivative_magnitude_computer_module.f',
'nonlinear_diffusion_module.f',
'main_module.f',
'main.f' ]
# Attach prefix to each source file
for i in range( len(SRC) ) :
SRC[i] = SRC_PREFIX + SRC[i]
env.Program(target = PROGRAM, source = SRC)
This produced:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
ifort -o src/array_1D_module.o -c src/array_1D_module.f
ifort -o src/array_2D_module.o -c src/array_2D_module.f
ifort -o src/array_3D_module.o -c src/array_3D_module.f
ifort -o src/density_parameters_module.o -c src/density_parameters_module.f
ifort -o src/derivative_magnitude_computer_module.o -c src/derivative_magnitude_computer_module.f
ifort -o src/diffusion3D_aos_solver_module.o -c src/diffusion3D_aos_solver_module.f
src/diffusion3D_aos_solver_module.f(7): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [DIFFUSION3D_AOS_Z_SUB_SOLVER_MODULE]
use diffusion3D_aos_z_sub_solver_module, only :
------------^
So density_parameters_module.f was compiled before thomas_algorithm_module.f, even though it comes after it in my list.
Is your program (as suggested) using modules? There's a couple of gotchas there:
FORTRANMODDIR needs defining: See http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=82725 for a discussion on that.
I found that having source files containing a mixture of module definitions and source code caused a certain amount of confusion.

linux/kernel.h : No such file or directory

I am going to write a Hello World module in Ubuntu 10.10 (with the kernel 2.6.35-28-generic). Headers are located:
/usr/src/linux-headers-2.6.35-28-generic
hello.c:
#include <linux/kernel.h>
#include <linux/module.h>
int init_module(void)
{
printk("Hello, world\n");
return 0;
}
void cleanup_module(void)
{
printk("Goodbye\n");
}
and Makefile:
CC = gcc
CFLAGS = -Wall -DMODULE -D__KERNEL__
hello.o: hello.c
$(CC) $(CFLAGS) -c hello.c
echo insmod hello.o to install
echo rmmod to delete
There is an error while make:
hello.c:1: fatal error: linux/kernel.h : No such file or directory
compilation terminated.
How do I solve this?
You can't just use a traditional-style Makefile with Linux kernel modules; while you might be able to force something to work, it'll be a painful experience.
Start by reading the Documentation/kbuild/modules.txt file; it'll describe exactly what you need to do when writing a module Makefile so that it can hook neatly into the kernel's Kbuild environment. Your Makefile will probably look something like this:
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m := 8123.o
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
else
# normal makefile
KDIR ?= /lib/modules/`uname -r`/build
default:
$(MAKE) -C $(KDIR) M=$$PWD
# Module specific targets
genbin:
echo "X" > 8123_bin.o_shipped
endif
Please trust me on this; while you might think you're "just one small change" from getting your own Makefile to work, even minor changes in kernel version will completely destroy your build all over again. Just take the hour now to write a Kbuild-compatible Makefile for your module. I wasted weeks of my life trying to maintain a pre-existing Makefile when the Kbuild infrastructure was introduced. Every new kernel caused me to lose hours of productivity.
For me this file ("linux/kernel.h") is in the package linux-libc-dev (Kubuntu 10.10).
Do you have /usr/src/linux symbolic link to your /usr/src/linux-headers-2.6.35-28-generic ?
If not then create one using following commands
# cd /usr/src
# ln -sfn linux-headers-2.6.35-28-generic linux
just as what #sarnold said , you should use the different Makefile.Just as following:
obj-m += hello.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
and use the command:
insmod hello.ko
to install this module.