I am trying to create a recipe in yocto to build a package for SDK - https://github.com/nodejs/http-parser
Here is my http-parser.bb. However, when I am trying to build using - "-c populate_sdk", I get the error that no Makefile found.
What am I missing here? My source code has Makefile. I am following the book by Rudolf - Yocto book and I can't see anything except adding the following from chapter 8 - Software package recipe.
do_install() {
oe_runmake install PREFIX=${D}
}
Here is my recipe file.
SUMMARY = "http-parser"
DESCRIPTION = "This is a parser for HTTP messages written in C. It parses both requests and responses. The parser is designed to be used in performance HTTP applications. It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. Depending on your architecture, it only requires about 40 bytes of data per message stream (in a web server that is per connection)."
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE-MIT;md5=9bfa835d048c194ab30487af8d7b3778"
SRC_URI[md5sum] = "59f8fce33369f2ef2a45f46b6b5420bc"
SRC_URI[sha256sum] = "865e0ec42f3c0a949654ebff98d538dd828a239392b502d42e15cb1e5bb28895"
SRCREV = "${AUTOREV}"
PV = "r${SRCREV}"
PR = "r2"
ALLOW_EMPTY_${PN} = "1"
SRC_URI = "https://github.com/nodejs/http-parser.git"
S = "${WORKDIR}/git"
PARALLEL_MAKE = ""
After running bitbake, I get an error no Makefile found.
Related
I am rather new to eclipse hawkbit and SWupdate I have been trying to do a test implementation on a RPi before I go with the production implementation.
I have Hawkbit up and running but I am having several problems with SWupdate, I have built a core-image-full-cmdline.wic and the .swu update Image along with it:
This is the local.conf:
MACHINE = "raspberrypi3"
IMAGE_FSTYPES += "wic"
RPI_USE_U_BOOT = "1"
KERNEL_IMAGETYPE = "uImage"
IMAGE_INSTALL_append = " kernel-image kernel-modules"
#WKS_FILES_raspberrypi3 = "ts-raspberrypi.wks"
PREFERRED_PROVIDER_u-boot-fw-utils = "libubootenv"
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
ENABLE_UART = "1"
I also got this error when I changed the IMAGE_FSTYPE from ext4 rpimg to wic:
ERROR: update-image-1.0-r0 do_swuimage: swupdate cannot find image file: /home/aswin/yocto/build/tmp/deploy/images/raspberrypi3/core-image-full-cmdline.ext4.gz
ERROR: Logfile of failure stored in: /home/aswin/yocto/build/tmp/work/raspberrypi3-poky-linux-gnueabi/update-image/1.0-r0/temp/log.do_swuimage.87006
ERROR: Task (/home/aswin/yocto/layers/meta-swupdate-boards/recipes-extended/images/update-image.bb:do_swuimage) failed with exit code '1'
So I had to change the update-image.bb FSTYPE = ".wic"
And when I comment this out #WKS_FILES_raspberrypi3 = "ts-raspberrypi.wks"
Then flash the image to a sd card and boot it nothing really shows up except for a blinking line. If I leave it, then the .swu file is way too big to upload it to hawkbit.
How do you expect it to work when you have HW compatibility errors, JSON file corrupted errors, forget about the hawkbit for now, and try to see if your sw-description file is creating the correct swu image file that updates the rootsfs or whatever you want to update using mongoose webserver and only then move on to the hawkbit.
First solve the errors that are coming before
suitable .swu image not found
Edited: please also put the sw-descirption file that you are using to create your swu file for further help.
Background
I have a microcontroller board which has STM32MP157 chip on it, with a development board. The manufacturer provides a Yocto BSP layer for this device and the development board and it is found on an open Github repository.
The important thing to note is that the BSP layer applies important devicetree patches to the stable release of the Linux kernel.
What I want
I would like to modify parts of the devicetree that is provided by the manufacturer's BSP layer, basically add to it.
What I have done
I have created a layer, named meta-mx-dts, put it after the manufacturer supplied layer in the build/conf/bblayers.conf file, and made it with higher priority by setting BBFILE_PRIORITY_meta-mx-dts in meta-mx-dts/conf/layer.conf (so that it applies after the manufacturer supplied layer). Finally, I made a file linux-stable_5.4.bbappend as follows:
FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
SRC_URI_append = "file://dts.patch"
and placed the dts.patch file properly.
The error I get
The error stack can be summarized by this line (from the error stack):
error: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts: does not exist in index
Where stm32mp157c-dhcom-pdk2.dts is the devicetree file to be created by the patches in the manufacturer's BSP layer. My patch applies to that file specifically.
What I have tried so far
I have tried different ways to append/prepend the dts.patch to the SRC_URI variable, until I got it appear after the patches directory applied by the BSP layer, by checking in the following ways in the treminal:
bitbake -e linux-stable | grep SRC_URI
bitbake -e virtual/kernel | grep SRC_URI
However, that didn't solve the issue. I also tried to make the SRC_URI append operation to be specific to the machine:
SRC_URI_append_dh-stm32mp1-dhcom-pdk2 = "file://dts.patch"
That didn't help either.
UPDATE
I have also tried to append to KERNEL_FEATURES variable and use .scc file, where I specify patches, as follows:
# The .bbappend file
KERNEL_FEATURES_append = " mx.scc "
SRC_URI_append = " file://mx.scc;type=kmeta "
with the file mx.scc being like:
define KMACHINE dh-stm32mp1-dhcom-pdk2
define KTYPE standard
define KARCH arm
branch dh-stm32mp1-dhcom-pdk2
patch dts.patch
With no effect.
Need your help
Thanks
I am currently migrating from Poky Fido to Sumo. We have a few custom recipes in a separate layer (meta-user) which contains a busybox_1.23.2.bb recipe customized to the needs and derived from the Fido layer. After migrating to Sumo, I am trying to build this recipe, but now it fails at do_compile (Link to the log file is below).
https://pastebin.com/yYXJnC2e
Here is the Build Configuration:
Build Configuration:
BB_VERSION = "1.37.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal-4.8"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "arm-cortex-a8"
DISTRO = "poky"
DISTRO_VERSION = "2.5"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU = "hard"
meta-networking
meta-python = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
meta-userbsp-ti
meta
meta-poky
meta-yocto-bsp
meta-user-common = "<unknown>:<unknown>"
meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
workspace = "<unknown>:<unknown>"
NOTE: Host OS is CentOS_7.1
Both limits.h and byteswap.h don't exist in Poky-Fido as well, but compiles without problems, unlike on Sumo. Does this have to do with the wrong Toolchains used or due to glibc (FYI: glibc_2.27 is been used)? If it has to do with the Toolchains, which one should I be using and how do I go about it?
Thanks in advance!
My main objective is to run snappy player (https://wiki.gnome.org/Snappy) on target machine (BeagleBone Black) so, I wrote a recipe for Snappy player(snappy_1.0.bb) as below
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=686e6cb566fd6382c9fcc7a557bf4544"
SRCREV = "e73fabce4c397b40d490c74f6a6a0de000804f42"
SRC_URI = "git://git.gnome.org/snappy"
S = "${WORKDIR}/git"
RDEPENDS_${PN} = "gtk+3 gstreamer1.0 glib-2.0 clutter-1.0 gstreamer1.0-plugins-base libxtst clutter-gst-3.0 clutter-gtk-1.0 libx11 cairo gdk-pixbuf"
# inherit line
inherit pkgconfig autotools
FILES_${PN} += "${datadir}/*"
Added this recipe name in local.conf
IMAGE_INSTALL_append = " snappy"
The build (bitbake core-image-sato) was successful, when I ran "snappy" on target(BeagleBone Black) I am getting below error response.
sh-4.4# snappy
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI2: failed to authenticate
(snappy:763): clutter-CRITICAL **: Unable to initialize clutter: Unable to initialize the clutter backend: no available drivers found.
As per my Understanding in my recipe I have resolved all dependencies for Snappy player (such as clutter, gstreamer, gtk etc.).
I'm unable to figure out why snappy player is throwing error?
Even tried by adding PREFERRED_PROVIDER_virtual/egl ?= "mesa"
in local.conf yet getting the same error.
I am trying to build Boost library locally and want to use it as a local_repository in my own project. I am referring to this (https://github.com/nelhage/rules_boost) for help.
I have a directory tree like this:
boost/ // root of the boost project
|
bazel/
| |
| boost.bzl // contains "boost_library" function from https://github.com/nelhage/rules_boost/blob/master/boost/boost.bzl
| |
| BUILD // empty
boost/ // the original boost headers folder from original boost dist
|
lib/ // the original boost sources folder from original boost dist
|
BUILD
|
WORKSPACE
The BUILD file looks like this one:
https://github.com/nelhage/rules_boost/blob/master/BUILD.boost
with properly loading boost.bzl
The WORKSPACE is just:
workspace( name = "boost" )
The issue:
Now I am trying to build individual components (bazel build //:<component>).
Some of the components (Boost.Container, Boost.Test) are failing to build for a similar reason (not finding header files).
bazel build //:container 1 ↵
INFO: Found 1 target...
ERROR: /home/spyder/codebase/boost/BUILD:103:1: C++ compilation of rule '//:container' failed: Process exited with status 1 [sandboxed].
libs/container/src/global_resource.cpp:12:51: fatal error: boost/container/pmr/memory_resource.hpp: No such file or directory
compilation terminated.
Use --strategy=CppCompile=standalone to disable sandboxing for the failing actions.
Target //:container failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.519s, Critical Path: 0.18s
bazel build //:test 1 ↵
INFO: Found 1 target...
ERROR: /home/spyder/codebase/boost/BUILD:581:1: C++ compilation of rule '//:test' failed: Process exited with status 1 [sandboxed].
libs/test/src/junit_log_formatter.cpp:11:51: fatal error: boost/test/impl/junit_log_formatter.ipp: No such file or directory
compilation terminated.
Use --strategy=CppCompile=standalone to disable sandboxing for the failing actions.
Target //:test failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.027s, Critical Path: 0.82s
Can anyone guide me on fixing it ?
EDIT:
I also tried to query the expanded cc_library rule by bazel query --output=build //:container and got this
cc_library(
name = "container",
visibility = ["//visibility:public"],
generator_name = "container",
generator_function = "boost_library",
generator_location = "/home/spyder/codebase/boost/BUILD:103",
licenses = ["notice"],
deps = ["//:config", "//:core", "//:intrusive", "//:move"],
defines = [],
includes = ["boost/container/"],
copts = ["-Wno-unused-value"],
srcs = ["//:libs/container/src/alloc_lib.c", "//:libs/container/src/dlmalloc.cpp", "//:libs/container/src/dlmalloc_2_8_6.c", "//:libs/container/src/dlmalloc_ext_2_8_6.c", "//:libs/container/src/global_resource.cpp", "//:libs/container/src/monotonic_buffer_resource.cpp", "//:libs/container/src/pool_resource.cpp", "//:libs/container/src/synchronized_pool_resource.cpp", "//:libs/container/src/unsynchronized_pool_resource.cpp"],
hdrs = [ ....... , "//:boost/container/pmr/map.hpp", "//:boost/container/pmr/memory_resource.hpp", "//:boost/container/pmr/monotonic_buffer_resource.hpp", "//:boost/container/pmr/polymorphic_allocator.hpp", ........ ],
)
Very shockingly, the source file which is complaining (libs/container/src/global_resource.cpp) and the header that it is complaining about (boost/container/pmr/memory_resource.hpp) are both correctly included in the srcs and hdrs list.
I played with your rules a bit and the biggest problem I see is incomplete dependencies. For example I tried :algorithm component, and that needs to depend on :tuple. I guess you just needs to make sure all dependencies are set correctly.
I played more with container, and the problem I encountered was incorrect include dirs. If you run your build with -s flag, bazel will output all the command lines so you can inspect them and check that -isystem flags contain the directory that contains boost/container/... . What can also help you is the bazel flag --sandbox_debug, which will prevent the sandbox directory from being deleted so you can see which files are where and also you can reproduce the compiler invocation without running through bazel.
Last, bazel does not understand .ipp header extension yet (tbh I've never heard of it, but I also know next to nothing about boost). I have a change in flight that will introduce this.