Yocto external kernel module including public header - header-files

I have written an external kernel module, very close to the hello_mod example:
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
However, my kernel module also provides a public header file to be provided to all code using the module. However, this header is not installed to sysroot, nor to populate_sdk.
How can I achieve this? Do I have to manually add the file via FILES_${PN}_dev or modify the Makefile?

After chatting on yocto mailinglist I got the impression, that it is uncommon for kernel modules to install their own headers. Hence I opted for a simple do_install_append() into hello-mod.bb, like this:
do_install_append() {
install -d ${D}${includedir}/
install -m 644 ${S}/header.h ${D}${includedir}/header.h
}
FILES_${PN} += "${includedir}"
With a DEPENDS entry other recipes can now access the header via sysroot.
Regarding a solution inside the module Makefile: I found some reference about "make headers_install" but couldn't figure out to integrate this into my module Makefile, see How do I specify header files for make headers_install in an out-of-tree kernel module?

Related

Applying patch to a package outside of buildroot directory

I am trying to apply a patch to a package that is not located within buildroot/package but elsewhere.
I have added to my buildroot .config the following
BR2_GLOBAL_PATCH_DIR="absolute/path/to/folder"
The folder is correct because if the path wasn't correct, buildroot would error out. So the path to the directory is good.
Using the instructions here and here. I've added a subdirectory with the name that matches the package and adding the patch to that subdirectory but nothing happens.
Buildroot never outputs it's trying to apply patches which leads me to believe buildroot isn't even looking in the BR2_GLOBAL_PATCH_DIR or calling the apply-patches.sh in buildroot/support/scripts/.
Why isn't buildroot trying to apply the patch to my package?
Buildroot applies patches only to packages with downloaded source code. In other words, it doesn't apply patches to packages that are taken locally with FOO_SITE_METHOD = local or with FOO_OVERRIDE_SRCDIR = /path/to/foo.
If you see output like this:
>>> foo custom Syncing from source dir /path/to/foo
you are in this situation.
-EDIT-
Applying patches in this case is not supported by Buildroot. However, you can work around it with something like this:
define FOO_APPLY_PATCHES
$(APPLY_PATCHES) $(#D) $(addsuffix /$(RAWNAME),$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \*.patch
endef
FOO_POST_RSYNC_HOOKS += FOO_APPLY_PATCHES

"unsupported/Eigen/CXX11/Tensor: No such file or directory" while working with TensorFlow

I'm trying to use tensorflow as a external library in my C++ application (mainly following this tutorial). What I done so far:
I have cloned the tensorflow reporitory (let's say, that the repo root dir is $TENSORFLOW)
Run /.configure (which all settings default, so no CUDA, no OpenCL etc.).
Build shared library with bazel build -c /opt //tensorflow:libtensorflow_cc.so (build completed successfully)
Now I'm trying to #include "tensorflow/core/public/session.h". But after including it (and adding $TENSORFLOW and $TENSORFLOW/bazel-genfiles to include path), I'm receiving error:
$TENSORFLOW/tensorflow/third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1:42:
fatal error: unsupported/Eigen/CXX11/Tensor: No such file or directory
There is a github issue created for similar problem, but it's marked as closed without any solution provided. Also I tried with master branch as well as v.1.4.0 release.
Do you happen to know, what could cause this kind of problem and how to deal with it?
I (and many others) agonized over the same problem. It probably can be solved using bazel but I don't know that tool well enough and now I solve this using make. The source of confusion is that a file named Tensor is included and it itself includes a file named Tensor, which has caused some people to wrongly conclude Tensor is including itself.
If you built and installed the python .whl file there will be a tensorflow directory in dist-packages and an include directory below that, e.g. on my system:
/usr/local/lib/python2.7/dist-packages/tensorflow/include
From the include directory
find . -type f -name 'Tensor' -print
./third_party/eigen3/unsupported/Eigen/CXX11/Tensor
./external/eigen_archive/unsupported/Eigen/CXX11/Tensor
The first one has
#include "unsupported/Eigen/CXX11/Tensor"
and the file that should satisfy this is the second one.
So to compile session.cc that includes session.h, the following will work
INC_TENS1=/usr/local/lib/python2.7/dist-packages/tensorflow/include/
INC_TENS2=${INC_TENS1}external/eigen_archive/
gcc -c -std=c++11 -I $INC_TENS1 -I $INC_TENS2 session.cc
I've seen claims that you must build apps from the tensorflow tree and you must use bazel. However, I believe all the header files you need are in dist-packages/tensorflow/include and at least for starters you can construct makefile or cmake projects.
Slightly off-topic, but I had the same error with a C++ project using opencv-4.5.5 and compiled with Visual Studio (no problem with opencv-4.3.0, and no problem with MinGW).
To make it work, I had to add to my root CMakeLists.txt:
add_definitions(-DOPENCV_DISABLE_EIGEN_TENSOR_SUPPORT)
If that can help someone...
the problem was actually in the relative path of the header file taken in the Tensor file.
installed path for Tensor is /usr/include/eigen3/unsupported/Eigen/CXX11/Tensor
but mentioned in the Tensor file is "unsupported/Eigen/CXX11/Tensor"
So there should be an entry upto /usr/include/eigen3/ in the project path to run this correctly so that it can be used.

Installing SML/NJ library

I need to install QCheck/SML unit test library for ML.
I could git clone the code, and create the .cm file, but I'm not sure how to copy the generated file into where. The document simply says (http://contrapunctus.net/league/haques/qcheck/qcheck_2.html):
2.1 SML/NJ
For Standard ML of New Jersey, the CM library specification ‘qcheck.cm’ should be all you need. The default target of make -f
Makefile.nj will ask CM to build and stabilize this library. This
creates a file ‘.cm/x86-unix/qcheck.cm’ (alter the arch/os tag as
needed) which may be copied into the standard CM library path and
added to the ‘pathconfig’.
I used brew install smlnj for the ML installation in Mac, so I have SMLNJ_HOME at /usr/local/Cellar/smlnj/100.78/SMLNJ_HOME.
What is the CM path library in this? In general, how to install a library into SML/NJ?
Edit
From Matt's answer, this is how I made it work.
Setup
Copy the whole qcheck directory into /usr/local/Cellar/smlnj/110.78/SMLNJ_HOME/lib.
Make ~/.smlnj-pathconfig file.
Add qcheck.cm /usr/local/Cellar/smlnj/110.78/SMLNJ_HOME/lib/qcheck in the file.
Usage (in REPL)
CM.make "$/qcheck.cm";
open QCheck;
Things to consider.
I couldn't use the stabilized libraries (qcheck/.cm/x86-unix/qcheck.cm). So, I had to copy the whole directory.
For user's library, I think the install location can be anywhere, as the ~/.smlnj-pathconfig can point to the directory.
For importing a structure in the same directory, use "FILENAME"; is needed instead of CM.make.
The CM library path is located in SMLNJ_HOME/lib. You can place the .cm file here. The instructions say to modify the pathconfig file, however, I would suggest creating a .smlnj-pathconfig file in your home directory instead. You are going to want to then paste the following line into that file:
qcheck.cm <path to directory containing qcheck.cm file>
You can then reference this in one of your .cm files using the anchor name: $/qcheck.cm. I've not used stabilized libraries before, and the generated .cm file is giving me a bunch of errors. If you instead use the qcheck.cm file from the root directory of the qcheck repo, it seems to work for me. Perhaps someone else can comment on why I am getting these errors.

Ns3 adding a new module-- gcc not finding included headers

I am trying to add a new custom module to NS3Network Simulator 3 and I am having trouble making the header files of the module visible to the compiler.
Here is what I did:
1.I followed thisguide to add a new noc module using the createModule script.
2.I went on and copied my module files into the new created noc directory and made waf(the build system ns3 uses) aware of my new files through editing the wscript file.
3.It is my understanding that with all this set up(I probably wrong) that with this set up,running the waf commands to rebuild ns3 should rebuild ns3 with my new module.
To build I give the following commands:
./waf clean
./waf configure --enable examples
./waf build
The system goes on and builds ns3 and when it gets to my noc module it throws errors about objects of a Scalar Class not being defined in the scope.This usually means that I haven't included the header files but I have tried to copy them with other module files and included them with statements like #include "nstime.h" .With this the problem persisted. I tried copying the header with the definition of my class in the /usr/include directory and inlcuded it with #include and the problem is still there.
I realize this is a long post ,I am sorry but I would really appreciate it if somebody helped point out what I am missing.Thank you for your time.
You should also make sure in your wscript file that you add the dependencies of your module to other ns-3 modules as explained here.

Where Should Shared Object Files Be Placed?

I am venturing into the land of creating C/C++ bindings for Python using pybindgen. I've followed the steps outlined under "Building it ( GCC instructions )" to create bindings for the sample files:
http://packages.python.org/PyBindGen/tutorial.html#a-simple-example
Running make produces a .so file. If I understand how .so files work, I should be able to import the classes in the shared object into Python. However, I'm not sure where to place the file and how to let Python know where it is. Additionally, do the original c/c++ source files need to accompany the .so file?
So far I've tried placing the file in /usr/local/lib and adding that path to DYLD_LIBRARY_PATH to the .bash_profile. When I try to import the module from within the Python interpeter an error is thrown stating that the module can not be found.
So, my question is: What needs to be done with the generated .so file in order for it to be used by a Python program?
Python looks for .so modules in the same directories where it searches python ones. So you have to install it as you would normal python module either somewhere that is on python's sys.path by default (/usr/share/python/site-lib or something like that—it'd distribution-dependent) or add the directory to PYTHONPATH environment variable.
It's python that's loading the module using dlopen, not the dynamic linker, so LD_LIBRARY_PATH (note, there is no DY) won't help you.
Same as all other Python modules. It must be within one of the locations given in sys.path.