Yocto recipe to manage Go dependencies with dep tool - go

Update: This question is already SOLVED. I'm re-editing the question to update to the fixed state.
I'm trying to write a recipe that uses dep tool to resolve dependencies of a go related project before building it. I'm using the 'poky' layer of the 'rocko' Yocto project branch. That branch provides recipes to build the go compiler and the dep dependencies tool.
My initial recipe fetches source code from a bitbucket repository:
GO_IMPORT = "bitbucket.org/path/to/my_project"
SRC_URI = "git://${GO_IMPORT}/protocol=http;user=${GIT_USER}:${GIT_PASS};destsuffix=${PN}-${PV}/src/${GO_IMPORT}"
Then I add this:
inherit go
DEPENDS += "go-dep"
And after I add this function:
do_compile_prepend() {
dep init
dep ensure
}
Yocto complains with this error:
run.do_compile.8543: line 118: dep: command not found
After reading some of your answers below, I add suggested patch in your answers at the end of my poky/meta/recipes-devtools/go/go-dep_0.3.0.bb recipe file - thanks a lot!! :-)
BBCLASSEXTEND = "native nativesdk"
After I execute some bitbake commands:
$ bitbake -c cleanall go-dep-native
$ bitbake go-dep-native
Bitbake process ends ok, displaying no errors nor warnings. The native go-dep tool has been built into tmp/work/x86_64-linux/go-dep-native directory and is properly installed into tmp/sysroots-components/x86_64/go-dep-native/usr/bin.
I modify the do_compile_prepend() function as shown below:
do_compile_prepend() {
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.toml
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.lock
cd ${WORKDIR}/build/src/${GO_IMPORT}
dep init
dep ensure
}
I modify DEPENDS in my recipe like this:
DEPENDS = "go-native go-dep-native"
Note the go-dep has been removed (I don't need dep tool on the target device, just to resolve dependencies on the native platform).
After that, I execute this command:
$ bitbake <foo>
The do_compile stage works fine, but some errors appear when doing the do_package stage:
ERROR: <foo>-1.0-r0 do_package: QA Issue: File '/usr/bin/dep' from <foo> was already stripped, this will prevent future debugging! [already-stripped]
ERROR: <foo>-1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: <foo>-1.0-r0 do_package: Function failed: do_package
These errors are fixed appending this at the end of my recipe:
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"
RDEPENDS_${PN}-staticdev += "bash"
RDEPENDS_${PN}-dev += "bash"
I don't know if this is the best way to solve my issue, but at least now it works fine. Any advice to improve this recipe is wellcome. Thank you in advance! :-)

The DEPENDS += "go-dep" means that your target recipe can include headers or link libs provided by go-dep, but you can't run the dep command, if you need run dep command, you need depend on go-dep-native:
DEPENDS += "go-dep-native"
But yocto doesn't provide go-dep-native currently, so you have to add:
BBCLASSEXTEND = "native"
to meta/recipes-devtools/go/go-dep_XXX.bb.
Then you can run dep command in do_compile_prepend()

I just sent the patch[1] to enable the native and nativesdk support for the recipe.
https://patchwork.openembedded.org/patch/147390/

Assuming you're using the same recipe as the one here, you should be able to refer to the ${GO_INSTALL} variable in your do_compile_prepend build step. If not, try running -c devshell with your bitbake command, like:
bitbake <package name> -c devshell
and look for the path of the dep tool.

Related

Building a Sample Cinder Program in Ubuntu

I am trying to run a sample cinder in my device, but I am facing problem to do so,
First of all I cloned the cinder's repository from github and build it.
mkdir build && cd build
cmake ..
The build was sucessfull.
The documentation states that,
The runtime output directory for different configurations will
automatically end up within different folders (e.g.
lib/macosx/Debug/libcinder.a and lib/macosx/Release/libcinder.a),
However when I try to run the sample using CLion, I get following error.
ninja: error: '/home/icancode/Cinder/lib/linux/x86_64/ogl/Debug/libcinder.a', needed by 'Debug/BasicAppMultiWindowApp/BasicAppMultiWindowApp', missing and no known rule to make it
My CMakeLists.txt is:
cmake_minimum_required(VERSION 3.10)
project(BasicAppMultiWindowApp)
get_filename_component( CINDER_PATH "~/Cinder" ABSOLUTE )
include( "${CINDER_PATH}/proj/cmake/modules/cinderMakeApp.cmake" )
ci_make_app(
APP_NAME "BasicAppMultiWindowApp"
CINDER_PATH ${CINDER_PATH}
SOURCES BasicAppMultiWindowApp.cpp
)
Any solution to this, I have been trying this for hours now. Thanks in Advance.
You should use make -j8 too while building like:
mkdir build && cd build
cmake .. && make -j3

How can i setup meson and ninja on Ubuntu-Linux to produce the expected .a file by use of MakeFile?

Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.

config.status: error: cannot find input file: `po/Makefile.in.in'

I hit this error message while trying to build gnote using GNU Autotools.
I had first run:
$ git clean -xf # to clean the tree of untracked files, then
$ autoreconf # to create the script named `configure`, and finally
$ ./configure # to check my system, and create Makefiles from their templates
Neither po/Makefile.in.in nor po/Makefile.in exist in the source tree that I downloaded.
Yet configure needs to make this po/Makefile, as called for in the root Makefile.am in this line:
SUBDIRS = data src po help
Where do I get, or how do I make, po/Makefile.in.in?
Like all Gnome related packages, gnote uses many steps of buildsystem setup beyond just running autoreconf.
The autogen.sh script gnote comes with should run all the required steps to set up the buildsystem.
As usual, run the autogen.sh script with the --help parameter if you want to call configure separately.
po/Makefile.in.in is created by running intltoolize from the intltool package. It needs to be run from the project tree's root directory.
There isn't much documentation on intltoolize that I could find except for the brief man page, but it's source code says that that it's a fork of an older utility called libtoolize, and it's a relatively short script.
(BTW, if you don't already have intltoolize installed, you can figure out which package installs it, with this: sudo apt-file find intltoolize.)
*.in files are templates used by AutoMake to create a Makefile.
.in.in is a soft link to /usr/share/intltool/Makefile.in.in.

Using populate_sdk to include kernel headers

How do I include the linux kernel headers as part of the SDK package in Yocto?
I'm using Yocto 1.8 (fido) in an embedded project and want to do out-of-tree kernel module development. Currently, I can build my kernel modules (apart from bitbake) by pointing my $KERNEL_PATH to the poky/build/tmp/work-shared/<machine>/kernel-source/ directory when I run make. I don't want to do this in the long term, however, since others need to easily build the modules without installing and building a full image from bitbake.
I can generate an SDK using bitbake myimage -c populate_sdk. However, this doesn't include the kernel headers (all I ever see is sysroots/<mach>/usr/include/linux). How do I cause the kernel headers to be included in the SDK package? Also, I don't want the kernel headers to show up as part of my target image.
[Edit]
My image recipe is as follows:
EXTRA_IMAGE_FEATURES_append = " eclipse-debug debug-tweaks"
TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake"
IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL} util-linux kernel-modules netbase busybox base-passwd base-files sysvinit initscripts bash gdbserver strace sysfsutils dtc gawk ethtool grep sed wget iptables oprofile net-tools dropbear rsync stress-ng rt-tests i2c-tools"
inherit core-image
The kernel I'm using is linux-altera-ltsi-rt in the meta-altera layer.
From the fido release, the handling of kernel builds has been changed. In previous releases, you could usually just skip down to the usage example below.
In fido or any 1.8+, if you want the kernel src and build system available in the SDK, you should add
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
to your image recipe. That will ensure that the new, kernel-devsrc package is installed into your toolchain.
The procedure below is just to ensure that the rest of the workflow is fully understood (even though it's not strictly part of the original question).
Usage Example
Lets assume a module Makefile as follows:
obj-m += hello-1.o
all:
make -C $(KERNEL_SRC) M=$(PWD) modules
clean:
make -C $(KERNEL_SRC) M=$(PWD) clean
Example taken from The Linux Kernel Module Programming Guide (Note that the actual commands needs to have a tab character for indentation).
Then you'll have to define KERNEL_SRC to be sysroots/<mach>/usr/src/kernel/, either in the Makefile, or from your make call. (Using a variable like KERNEL_SRC will ensure that your module recipe automatically picks the right location when building using bitbake).
To manually build your kernel module:
Source the environment-* file for your SDK.
Go to you modules directory.
KERNEL_SRC=<sdk-install-path>/sysroots/<mach>/usr/src/kernel LDFLAGS="" make However, this will fail, as fixdep can't be found. We'll fix this manually.
cd <sdk-install-path>/sysroots/<mach>/usr/src/kernel
make modules_prepare
If this needs to be run with sudo, be sure to source the environment file in the sudo environment: sudo bash -c "source <sdk-install-path>/environment-setup-<mach> && make modules_prepare"
Go back to your modules directory.
KERNEL_SRC=<sdk-install-path>/sysroots/<mach>/usr/src/kernel LDFLAGS="" make
This should now allow you to build your modules.
If you don't have the kernel source under sysroots/<mach>/usr/src/kernel/, we'll have to look into that.
anders answer is very good, but in recent versions of yocto the way to add kernel-devsrc seems to be
IMAGE_INSTALL += "kernel-devsrc"
which I found here: https://www.mail-archive.com/yocto#yoctoproject.org/msg36448.html
With Yocto Zeus (3.0.x) add this to your image recipe:
TOOLCHAIN_TARGET_TASK += "kernel-devsrc"
EDIT: Same for Gatesgarth (3.2.x) but the make scripts command has a new host dependency to libyaml-dev

How can I extract the environment variables used when building a recipe in Yocto?

I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:
bitbake mykernel -c devshell
Then in the new xterm window bitbake opened for me:
env | sed 's/\=\(.*\)/\="\1"/' > buildenv #put quotes around r-values in env listing
^D #(I leave the devshell)
Then copy this to my development directory and source it before running make with all of its options
KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
source ./buildenv && make -C $KERNEL_PATH V=1 M=`pwd` \
ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
LD=arm-linux-gnueabihf-ld AR=arm-linux-gnueabihf-ar
Now to my questions:
Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.
This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.
How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...
the sdk installer is what you are looking for:
bitbake your-image -c populate_sdk
then, from your build directory go to tmp/deploy/sdk
and execute the generated shell script.
this script will allow you to generate and install an sdk.
Not only the sdk will allow you to (cross) compile your kernel by providing the needed environment variables and tools, but it will also provide a sysroot + a standalone toolchain to help you easily (and by easily I mean really easily) crosscompile applications with the autotools (as long as you provide Makefile.am and configure.ac)
just source the environment-setup-* file, got to your kernel directory and compile.
Or, for application developpment based on the autotools,
go to the folder containing your project (sources + Makefile.am and configure.ac)
and do:
libtoolize --automake
aclocal
autoconf
automake -a
now your project is ready for compilation:
./configure $CONFIGURE_FLAGS
make
make install DESTDIR=path/to/destination/dir
If you're after a quick hack, instead of Ayman's more complete solution, the scripts run to complete each build stage are available in the directory:
./build/tmp/work/{target_platform}/{package}/{version}/temp/run.do_{build_stage}
These scripts can be run standalone from the ./temp/ directory, and contain all of the environment variables required.

Resources