Machine Details :
Linux beaglebone 3.8.13-bone47 armv7l GNU/Linux
Problem Details:
In a attempt to write out-of-tree modules on beagle bone black(as intree modules require me to compile/flash them again and again ), i have logged in to beagle bone black revc through ssh client, which gives me a command line interface via putty, as in general out-of-tree module development, i have tried to compile module with the following make file
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m := module.o
#module-objs := module.o
else
# normal makefile
KDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) M=$(PWD) modules
endif
resulting an error
root#beaglebone:~/lddgeek# make
make -C /lib/modules/3.8.13-bone47/build M=/root/lddgeek modules
make: *** /lib/modules/3.8.13-bone47/build: No such file or directory. Stop.
make: *** [default] Error 2
but when i parse to the path of KDIR i did not find build folder as we find it in an normal ubuntu installed on x86
if i have to develop drivers/modules out-of-tree on a Beagle how could i do that?
The reason i was not able to compile was i was missing the kbuild environment , i need to install kernel headers which will give me the capability to compile out-of-tree/external modules
#wget https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.sh
#chmod +x bb-get-rcn-kernel-source.sh
#./bb-get-rcn-kernel-source.sh
The above steps actually helped me in solving the errors faced , while i was able to insert,remove the hello world module that i was trying to build
Related
I am facing what I think is a configuration issue. I would like to build Paho MQTTSN gateway in Msys2 to make it run on Windows. What I do is :
I clone the repository, and I put it in /c/msys64/home/ folder
I add /c/msys64/mingw64/bin to $PATH because cmake cannot locate gcc otherwise.
I run ./build.sh udp command. Here is the output :
$ ./build.sh udp
Start building MQTT-SN Gateway udp
-- CMake version: 3.23.2
-- CMake system name: Windows
-- Timestamp is 2022-09-06T11:17:49Z
-- VERSION : 1.5.1
-- SENSORNET: udp
-- Definitions:
-- Configuring done
-- Generating done
-- Build files have been written to: C:/msys64/home/paho.mqtt-sn
make: *** No rule to make target 'MQTTSNPacket'. Stop.
make: *** No rule to make target 'MQTT-SNGateway'. Stop.
make: *** No rule to make target 'MQTT-SNLogmonitor'. Stop.
I tried to play around with cmake -G. I tried "MSYS Makefiles", but didn't had any chances.
I am still a bit confused with cmake, does someone have an idea?
By the way, paho is building fine on Ubuntu.
Thank you very much for your help
I'm trying to compile the "Source Code (.c)" example from this tutorial.
I have installed mruby using rbenv: rbenv install mruby-1.2.0
I get an error when trying to compile the program:
$ gcc -std=c99 -Imruby/include test_program.c -o test_program
test_program.c:1:10: fatal error: 'mruby.h' file not found
#include "mruby.h"
^
1 error generated.
How am I supposed to reference the mruby library when installing via rbenv/ruby-build?
Seems like rbenv install mruby-1.2.0 doesn't install header files of mruby(it's only a dump of build/host directory after mruby is built):
% ls $(rbenv prefix mruby-1.2.0)
LEGAL bin lib mrbgems mrblib src
You need
# get mruby's code
git clone https://github.com/mruby/mruby.git mruby
# build mruby
cd mruby && rake
# go back to directory of `test_program.c`
cd ..
before test_program.c's compilation instead.
And you need mruby/build/host/lib/libmruby.a -lm compile options too.
add -lm
in mruby is /include directory in my source is possible -I mruby_directory/include
next add ~/mruby/build/host/lib/libmruby.a
This is to compile and link a static library (so only a build time dependency) that the source is fetched from a repository (just like the source of the main program) on a ubuntu launchpad build bot.
currently i am doing:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $#
override_dh_auto_configure:
cd src/munt;cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu;make;make install
#...compile of the program that depends on mt32emu...
But it fails with:
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libmt32emu.a
CMake Error at cmake_install.cmake:36 (FILE):
file INSTALL cannot copy file
"/tmp/buildd/dosbox-0.74+20121225/src/munt/libmt32emu.a" to
"/usr/local/lib/libmt32emu.a".
make[2]: *** [install] Error 1
make[2]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225/src/munt'
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
I: unmounting /var/cache/pbuilder/ccache filesystem
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//2751 and its subdirectories
The idea is to install a static library dependency that is is not packaged in the ubuntu repositories in the launchpad pbuilder env, so it can be used as if it was a system dependency already.
If i try to do 'sudo make install' (and add sudo to the build-deps in debian/control), it asks me for the 'pbuilder' password when testing locally, which i'm assuming will hang the machine on the ubuntu buildbots.
edit: it actually fails on the buildbots because 'no tty present and no askpass program specified'.
There are several things you can do to clean up your rules file, especially when you are using dh.
In the % target, all of the dh command take a parameter builddirectory, which specifies what directory you are building in. This tells the builder to cd to that directory and then call commands (make, cmake, etc.).
In addition, you should just let dh install the files for you. This is done automatically. You shouldn't have to call make install manually.
Here's a slightly easier-to-read rules file:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $# --builddirectory=src/munt
override_dh_auto_configure:
cd src/munt && cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu
#...compile of the program that depends on mt32emu...
Is this just a permissions issue? (i.e. -- must use 'sudo' to install to '/usr/local'?)
Must you install it to '/usr/local'?
If it's just a static library, purely needed for the build of the "the program that depends on mt32emu" then you could put it anywhere, and just tell the dependent program where it is.
To install somewhere else, use -DCMAKE_INSTALL_PREFIX=/directory/where/you/have/write/privileges. Or use DESTDIR= with the make install.
I eventually 'solved' this by depending on launchpad repository dependencies, that is, building a whole package for the library and building that on launchpad and then importing the archive where that was placed to my other builds. Made it explicit i guess.
I'm trying to add DKMS support in a kernel module i'm working on.
I have placed the kernel module source with a static lib to be linked against in the following directory:
/usr/src/dpx/1.0
With the following files:
dkms.conf
Makefile
dpxmtt.c
lib.a
dkms.conf file is like this:
MAKE="make"
CLEAN="make clean"
BUILT_MODULE_NAME=dpx
BUILT_MODULE_LOCATION=src/
DEST_MODULE_LOCATION=/kernel/drivers/input/touchscreen
PACKAGE_NAME=dpxm
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
And the makefile is like this:
EXTRA_CFLAGS+=-DLINUX_DRIVER -mhard-float
obj-m += dpx.o
dpx-objs:= dpxmtt.o ../source/lib.a
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
The ../source/lib.a is an hack since when the makefile is invoked by the dkms building system it was saying that it couldn't be found in directory (the build directory), but since it was being copied to the source directory, i'm referencing it relatively.
When I call
sudo dkms build -m dpx -v 1.0
The result is almost perfect:
santos#NS-PC:~$ sudo dkms build -m dpx -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area....
make KERNELRELEASE=3.0.0-14-generic....
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/dpx/1.0/build/ for more information.
nsantos#NS-PC:~$
And the content of the log file is:
DKMS make.log for dpx-1.0 for kernel 3.0.0-14-generic (i686)
Thu Jan 19 11:07:54 WET 2012
make -C /lib/modules/3.0.0-14-generic/build M=/var/lib/dkms/dpx/1.0/build modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-14-generic'
CC [M] /var/lib/dkms/dpx/1.0/build/dpxmtt.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.o
Building modules, stage 2.
MODPOST 1 modules
CC /var/lib/dkms/dpx/1.0/build/dpx.mod.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-14-generic'
The module was built correctly but it ends with the error:
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
And I don't know what it means. Does anybody know?
Using:
$(shell uname -r)
in the Makefile it might be also wrong! The "shell uname -r" refers to the currently running kernel, but the main reason to use the dkms it's because it offers an automated method to recompile the kernel modules that reside outside of the kernel tree for every newly installed kernel. What i mean is that the Makefile might refers to a different kernel which the dkms is building the module for.
Use:
${kernelver} instead.
I had a similar problem. I think your BUILT_MODULE_LOCATION is set incorrectly to the src directory. It should be set in your example to the current directory, or you can just omit this variable and dkms would default to the current directory.
I have checked out the project on two different platforms and they give me -
on Ubuntu (have installed cmake and ccmake)
$ make
cd .build && make --no-print-directory
make[1]: *** No targets specified and no makefile found. Stop.
make: *** [all] Error 2
on Mac OS X (it starts off ...)
$ make
touch .configured
cd .build && cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
It seems like Ubuntu is still trying to compile using make?
cmake is a generator for build-system control files. It does not drive the build by itself, but is relies on external tools like make, nmake or some GUIs to build the software. The cd .build && cmake .. line in the osx build only updates the build system files, the build itself is driven by make there.
The error on the ubunto box probably is that there is no Makefile in .build, which means that cmake wasn't executed there, or it failed there previously. You can run cmake by hand with cd .build && cmake ...
If there's a configure script in the project, can you try:
./configure
make