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!
Related
I am always facing a problem if i wanted to build yocto or the qt toolchain.
for example in the first run i have give the following command where the issue occurs the first time:
bitbake meta-toolchain-qt5
following error message occurs:
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "raspberrypi3"
DISTRO = "poky"
DISTRO_VERSION = "3.1.6"
TUNE_FEATURES = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU = "hard"
meta = "dunfell:9ee329c18fbe0c42eaf3d43657ea30591f79143b"
meta-oe = "dunfell:346681e7bf9c78008a845fc89031be4fd4ceb3a1"
meta-poky
meta-yocto-bsp = "dunfell:9ee329c18fbe0c42eaf3d43657ea30591f79143b"
meta-qt5 = "dunfell:0d8eb956015acdea7e77cd6672d08dce18061510"
meta-raspberrypi = "dunfell:77190af02d48adc2b28216775e6318e9eeda571c"
meta-multimedia
meta-python
meta-networking = "dunfell:346681e7bf9c78008a845fc89031be4fd4ceb3a1"
Initialising tasks: 100% |##################################################################################################################################################################| Time: 0:00:02
Sstate summary: Wanted 0 Found 0 Missed 0 Current 329 (0% match, 100% complete)
NOTE: Executing Tasks
ERROR: gstreamer1.0-plugins-bad-1.16.3-r0 do_configure: meson failed
-------------------------------------------------------------------------------------------
| Run-time dependency gstreamer-sdp-1.0 found: YES 1.16.3
| Run-time dependency gstreamer-tag-1.0 found: YES 1.16.3
| Run-time dependency gstreamer-video-1.0 found: YES 1.16.3
| Run-time dependency gstreamer-check-1.0 found: YES 1.16.3
| Found CMake: NO
| Run-time dependency gstreamer-gl-1.0 found: NO (tried pkgconfig and cmake)
| Looking for a fallback subproject for the dependency gstreamer-gl-1.0
|
| meson.build:283:0: ERROR: Subproject directory not found and gst-plugins-base.wrap file not found
|
How can i solve this problem any ideas?
Thanks in advance
I encountered this issue as well and was able to track down the cause (though it probably doesn't apply to the original query if it was resolved by a clean build). In my case, I was building for an ELGFS Qt based system. There's a check in the meson.build file in gstreamer1.0-plugins-base that will disable the gstgl library build if an OpenGL Window system isn't found, and this was being triggered for me. gstreamer 1.16 does not support EGL as the window system but 1.18 does. Yocto upgraded to gstreamer 1.18 with the hardknott release, but we were relying on multiple supporting 3rd party recipes that were still on dunfell and couldn't upgrade.
In our case, gstreamer had been included as a dependency from qtmultimedia, but this was determined to be extraneous and could be resolved by excluding qtmultimedia or using a .bbappend file to remove gstreamer from the PACKAGECONFIG. If gstreamer is actually needed then the options are:
Use a windowing system (e.g., weston, or a custom wayland compositor), or
See if the gstreamer 1.18 recipe from hardknott can be made to work in the existing project, or
See if the entire project can be upgraded to use the hardknott release, so that gstreamer 1.18 is used by default.
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.
I am trying to include an external library (glm) in my bazel build, but I get undeclared inclusion the thing is I don't understand how to fix it and why, Because if I use the same BUILD script when I extract manually the library it builds fine.
I managed to make a very small repro of this problem, both the working case and the not working.
The not working example
My folder structure
glmExtBuild
WORKSPACE
externals
glm.BUILD
This is my WORKSPACE file
new_http_archive(
name = "glmExt",
url = "https://github.com/g-truc/glm/archive/0.9.9.0.tar.gz",
sha256 = "514dea9ac0099dc389cf293cf1ab3d97aff080abad55bf79d4ab7ff6895ee69c",
strip_prefix = "glm-0.9.9.0",
build_file = "externals/glm.BUILD",
)
This is my glm.BUILD file
package(default_visibility = ["//visibility:public"])
cc_library(
name= "glm",
defines= ["GLM_ENABLE_EXPERIMENTAL", "GLM_FORCE_RADIANS",
"GLM_FORCE_DEPTH_ZERO_TO_ONE"],
srcs=glob(["glm/**/*.cpp"]) + ["glm/detail/_fixes.hpp"],
hdrs=glob(["glm/**/*.hpp"])+glob(["glm/**/*.h"]),
includes = ["glm"],
textual_hdrs = glob(["glm/**/*.inl"]),
visibility = ["//visibility:public"],
)
And this is the errors that I get when I run
bazel build #glmExt//:glm --verbose_failures --sandbox_debug
ERROR: C:/users/...../external/glmExt/BUILD.bazel:121:1: undeclared inclusion(s) in rule '#glmExt//:glm':
this rule is missing dependency declarations for the following files included by 'external/glmExt/glm/detail/glm.cpp':
'external/glmext/glm/detail/_fixes.hpp'
'external/glmext/glm/detail/setup.hpp'
'external/glmext/glm/simd/platform.h'
'external/glmext/glm/fwd.hpp'
'external/glmext/glm/detail/setup.hpp'
'external/glmext/glm/detail/type_int.hpp'
'external/glmext/glm/detail/setup.hpp'
'external/glmext/glm/detail/type_float.hpp'
...
The working example:
My folder structure
glmBuild2
WORKSPACE
BUILD
glmSrc
https://github.com/g-truc/glm/archive/0.9.9.0.tar.gz extracted here
My WORKSPACE file is empty
And this is my BUILD file
package(default_visibility = ["//visibility:public"])
cc_library(
name= "glm",
defines= ["GLM_ENABLE_EXPERIMENTAL", "GLM_FORCE_RADIANS", "GLM_FORCE_DEPTH_ZERO_TO_ONE"],
srcs=glob(["glmSrc/glm/**/*.cpp"]) + ["glmSrc/glm/detail/_fixes.hpp"],
hdrs=glob(["glmSrc/glm/**/*.hpp"])+glob(["glmSrc/glm/**/*.h"]),
includes = ["glmSrc"],
textual_hdrs = glob(["glmSrc/glm/**/*.inl"]),
visibility = ["//visibility:public"],
)
Then when running the build command it finished successfully.
PS D:\......\glmBuild2> bazel build :glm --verbose_failures --sandbox_debug
INFO: Analysed target //:glm (1 packages loaded).
INFO: Found 1 target...
INFO: From Compiling glmSrc/glm/detail/glm.cpp:
glmSrc/glm/detail/glm.cpp(4): warning C4005: 'GLM_ENABLE_EXPERIMENTAL': macro redefinition
glmSrc/glm/detail/glm.cpp(4): note: command-line arguments: see previous definition of 'GLM_ENABLE_EXPERIMENTAL'
Target //:glm up-to-date:
C:/users/.../execroot/__main__/bazel-out/x64_windows-fastbuild/bin/libglm.a
INFO: Elapsed time: 1.830s, Critical Path: 1.30s
INFO: 3 processes, local.
INFO: Build completed successfully, 4 total actions
Does anybody have an idea?
Thanks
Update:
bazel version
Build label: 0.14.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Jun 1 13:06:29 2018 (1527858389)
Build timestamp: 1527858389
Build timestamp as int: 1527858389
Bazel issue:
https://github.com/bazelbuild/bazel/issues/5485
I tried the first example on linux, with bazel 0.15.0, and all worked once I added "." into includes attribute of glm. Do you have a possibility to test it on linux? Is it windows-only issue then? Which bazel version do you use?
Thanks for clarifications.
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 need to compile u-boot for my machine which is a 64 bits arm core with a 32-bit toolchain. The problem is that all
my other recipes use the 64 bits linaro toolchain. How can a tell bitbake to use the 32-bit linaro for the u-boot?
I've tried to add in my u-boot recipe things like:
UBOOT_ARCH = "arm"
PACKAGE_ARCH = "armv7a"
CROSS_COMPILE="arm-poky-linux-gnueabi-"
but nothing seems to work. It continues using aarch64-poky-linux-gcc to compile u-boot. My recipe at the moment looks like this:
DESCRIPTION = "U-boot for mymachine"
require recipes-bsp/u-boot/u-boot.inc
LICENSE = "GPLv2"
COMPATIBLE_MACHINE = "mymachine"
UBOOT_MACHINE_mymachine = "mymachine_config"
UBOOT_ARCH_mymachine = "arm"
PACKAGE_ARCH = "armv7a"
CROSS_COMPILE="arm-poky-linux-gnueabi-"
SRC_URI = "git://github.com/mymachine/u-boot-mymachine.git;branch=master \
file://boot.cmd"
SRCREV="${AUTOREV}"
PV = "v2016.03"
(...)
My machine.conf has:
require conf/machine/include/arm64/arch-armv8.inc