My rpmbuild log tells me all the flags used when calling configure:
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
--program-prefix= \
--disable-dependency-tracking \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--prefix=/opt/custom/SENSOR/Qt-5.15.2 \
--confirm-license \
--opensource
My problem is that the 'build' and 'host' flags (plus several others) are unknown commands for this particular configure script. How can I take complete control of the call to configure in my SPEC file? It's obviously not enough to add new flags to the %configure scriptlet, I need to remove flags that rpmbuild is adding by default.
It looks like the answer is to call configure directly instead of using the scriptlet. I.e., replace %configure with:
./configure --prefix=/opt/custom/SENSOR -confirm-license -opensource
Does any know of any good instructions explaining how to implement bluetooth into a yocto build.
I've added bluetooth into the MACHINE variable within the machine.conf and bluez to CORE_IMAGE_EXTRA_INSTALL in the local.conf located in my build directory. After building a new image, bluetoothd won't start because this condition is not met ConditionPathIsDirectory=/sys/class/bluetooth which is correct because that location doesn't exist on my system.
I'm new to yocto so any guidance would be greatly appreciated.
EDIT
So the /conf/bblayers has the following content:
BBLAYERS ?= " \
${BSPDIR}/poky/meta \
${BSPDIR}/poky/meta-poky \
${BSPDIR}/poky/meta-yocto-bsp \
${BSPDIR}/meta-atmel \
${BSPDIR}/meta-openembedded/meta-oe \
${BSPDIR}/meta-openembedded/meta-networking \
${BSPDIR}/meta-openembedded/meta-python \
${BSPDIR}/meta-openembedded/meta-multimedia \
${BSPDIR}/meta-swupdate \
${BSPDIR}/meta-custom \
${BSPDIR}/meta-openembedded/meta-initramfs \
The local.conf contains:
CORE_IMAGE_EXTRA_INSTALL += "\
bluez5 \
rpm \
valgrind \
"
DISTRO_FEATURES_append = " systemd bluetooth"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VURTUAL-RUNTIME_initscripts = "systemd-compat-units"
The .inc file in my custom layer contains:
#IMAGE_FEATURES += "ssh-server-openssh package-management"
IMAGE_INSTALL = "\
packagegroup-core-boot \
packagegroup-core-full-cmdline \
packagegroup-base-bluetooth \
kernel-modules \
libgpiod \
ntp \
sqlite3 \
openssl \
mtd-utils \
${CORE_IMAGE_EXTRA_INSTALL} \
"
inherit core-image
The machine conf file contains:
MACHINE_FEATURES = "apm ext2 ext3 pcmcia usbhost usbgadget"
Running
bitbake -e packagegroup-base | grep ^ADD_BT
Returns
ADD_BT="packagegroup-base-bluetooth"
bitbake -e <image-name> | grep ^IMAGE_INSTALL=
Returns
IMAGE_INSTALL=" packagegroup-core-boot packagegroup-core-full-cmdline packagegroup-base-bluetooth kernel-modules libgpiod ntp sqlite3 openssl mtd-utils apg-st-databases bluez5 rpm valgrind "
bitbake -e packagegroup-base-extended | grep ^RDEPENDS_packagegroup-base-extended=
returns
RDEPENDS_packagegroup-base-extended=" packagegroup-base packagegroup-base-wifi packagegroup-base-bluetooth "
First of all, MACHINE is dedicated to have one value which is the configuration file for your board, and you can not add bluetooth to it.
Yocto has an automatic bluetooth feature that handles adding bluetooth into your build. But it only there for boards that have a builtin bluetooth module.
For more info, check the machine features in the official Yocto doc here.
Let me now explain how bluetooth is integrated:
Basically, you only need some kernel defconfig configuration and bluez5 utility.
If you add the following line to local.conf or your custom machine file:
DISTRO_FEATURES_append = " bluetooth"
it will take effect if you build image that is based on core-image class, like core-image-minimal, because it contains a packagegroup-base-bluetooth as follows:
SUMMARY_packagegroup-base-bluetooth = "Bluetooth support"
RDEPENDS_packagegroup-base-bluetooth = "\
bluez5 \
"
RRECOMMENDS_packagegroup-base-bluetooth = "\
kernel-module-bluetooth \
kernel-module-l2cap \
kernel-module-rfcomm \
kernel-module-hci-vhci \
kernel-module-bnep \
kernel-module-hidp \
kernel-module-hci-uart \
kernel-module-sco \
${#bb.utils.contains('COMBINED_FEATURES', 'usbhost', 'kernel-module-hci-usb', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluetooth3c-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluecard-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-bluetoothuart-cs', '',d)} \
${#bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'kernel-module-dtl1-cs', '',d)} \
"
It will add packagegroup-base-bluetooth only in two conditions:
If bluetooth in DISTRO_FEATRUES and not in MACHINE_FEATURES and one of (pcmcia, pci or usbhost) in MACHINE_FEATURES
If bluetooth in COMBINED_FEATURES.
For more info on COMBINED_FEATURES check this link.
So, you just need to make true one of the conditions.
You can dig in more to understand more details, check:
poky/meta/classes/core-image.bbclass
poky/meta/recipes-core/packagegroups/packagegroup-base.bb
NOTE
If your bluetooth module has a dedicated kernel driver for example, you need to activate it in the kernel configuration via a fragment file.
Or create a module recipe for it.
EDIT
In order to add bluetooth just:
DISTRO_FEATURES_append = " bluetooth"
after that, you can check that bluetooth package is added. Here are details:
packagegroup-base-extended is always added to images based on core-image.bbclass and here is its content:
RDEPENDS_packagegroup-base-extended = "\
packagegroup-base \
${ADD_WIFI} \
${ADD_BT} \
${ADD_3G} \
${ADD_NFC} \
"
You see the ADD_BT variable? It is by default empty, and it is filled with packagegroup-base-bluetooth only if the first condition is true, and here is the detail from the recipe:
if "bluetooth" in distro_features and not "bluetooth" in machine_features and ("pcmcia" in machine_features or "pci" in machine_features or "usbhost" in machine_features):
d.setVar("ADD_BT", "packagegroup-base-bluetooth")
Now, to check that it is added, run:
bitbake -e packagegroup-base | grep ^ADD_BT
you should see: ADD_BT="packagegroup-base-bluetooth"
Also, you can check that packagegroup-base-extended is added to your image:
bitbake -e <your_image> | grep ^IMAGE_INSTALL=
Also, you can check if packagegroup-base-extended has packaged bluetooth package with it:
bitbake -e packagegroup-base-extended | grep ^RDEPENDS_packagegroup-base-extended=
EDIT2:
Your configuration looks okay, specially when packagegroup-base-bluetooth is shipped with in IMAGE_INSTALL.
I have some comments that you need to consider anyways:
local.conf:
Remove bluez5 from CORE_IMAGE_EXTRA_INSTALL
Change:
DISTRO_FEATURES_append = " systemd bluetooth"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VURTUAL-RUNTIME_initscripts = "systemd-compat-units"
with:
INIT_MANAGER = "systemd"
DISTRO_FEATURES_append = " bluetooth"
In your custom image file:
Put inherit core-image before IMAGE_INSTALL, because IMAGE_INSTALL of core-image will not take effect because it is ?=. So:
inherit core-image
IMAGE_INSTALL += "\
packagegroup-core-full-cmdline \
kernel-modules \
libgpiod \
ntp \
sqlite3 \
openssl \
mtd-utils \
"
Now, the only part that mention bluetooth is :
DISTRO_FEATURES_append = " bluetooth"
Now, check again for the variable tests.
This is not as simple as adding bluetooth as a DISTRO_FEATURE. Adding this only adds the systemd service and other user-space tools to the build. In fact, what you really need is your Linux kernel to support Bluetooth (i.e. add the necessary drivers and configuration to the Linux Kconfig). It can be done by means of enabling CONFIG_BT through menuconfig or directly on your config file. Additionally, you might want to include kernel drivers/plugins for the specific Bluetooth hardware you are using.
For /sys/class/bluetooth to exist, the kernel module bluetooth.ko, which is only autoloaded by systemd-udev if it actually finds a working Bluetooth hardware device.
I suggest you start by adding support for Bluetooth on your Linux kernel, recompiling and reflashing. Then all your user-space tools should start working if your BT hardware is able to be brought up.
This is a good resource that may help you: https://wiki.archlinux.org/title/bluetooth#Troubleshooting
I have built a Yocto image with the following configuration
# Architecture of the host machine
SDKMACHINE ?= "x86_64"
# Extra image configuration defaults
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
CORE_IMAGE_EXTRA_INSTALL += "openssh-sftp openssh-sftp-server"
INIT_MANAGER = "systemd"
INHERIT += "rm_work"
# Extra packages
LICENSE_FLAGS_WHITELIST = "commercial"
DISTRO_FEATURES:remove = " \
x11 \
directfb \
vulkan \
wayland \
"
DISTRO_FEATURES:append = " \
alsa \
opengl \
gles2 \
"
IMAGE_INSTALL:append = " \
coreutils \
qtbase-plugins \
qtbase-tools \
qtdeclarative \
qtdeclarative-plugins \
qtdeclarative-qmlplugins \
qtdeclarative-tools \
qtimageformats-plugins \
qtmultimedia \
qtmultimedia-plugins \
qtmultimedia-qmlplugins \
qtquickcontrols2 \
qtquicktimeline \
qtscript \
qtsvg \
qtsvg-plugins \
qtsystems \
qtsystems-qmlplugins \
qtsystems-tools \
rsync \
"
PACKAGECONFIG:append:pn-qtbase = " \
eglfs \
fontconfig \
gles2 \
libpng \
jpeg \
libs \
widgets \
"
# Image file system types to package
IMAGE_FSTYPES = "rpi-sdimg"
# Package management configuration
PACKAGE_CLASSES = "package_ipk"
MACHINE ??= "raspberrypi4"
DISTRO ??= "poky"
BBMULTICONFIG ?= ""
I could successfully build and generate and SDK. I can build the Qt app and deploy it to the device.
I set
QT_QPA_PLATFORM=eglfs
DISPLAY=:0
but I get the error
EGL library doesn't support Emulator extensions
Aborted
The error looks similar to
QT Creator can not remote run and debugging on i.Mx6 (buildroot)
but since the Pi doesn't have a Vivante driver, I wouldn't know what to pass. I tried to search for integrations
$ find / -name "*egl*"
/usr/lib/plugins/video/videonode/libeglvideonode.so
/usr/lib/plugins/videoeglvideonode
/usr/lib/plugins/egldeviceintegrations
/usr/lib/plugins/egldeviceintegrations/libqeglfs-emu-integration.so
/usr/lib/plugins/egldeviceintegrations/libqeglfs-kms-integration.so
/usr/lib/plugins/egldeviceintegrations/libqeglfs-kms-egldevice-integration.so
/usr/lib/plugins/platforms/libqminimalegl.so
/usr/lib/plugins/platforms/libqeglfs.so
but eglfs-kms or all other combinations I have tried, don't work.
If I try
QT_QPA_EGLFS_INTEGRATION=none
I get
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
Cannot find EGLConfig, returning null config
EGL Error : Could not create the egl surface: error = 0x300b
I am new to setting up the gRPC web based client side. Our backend is already up and running on Go with gRPC. I am testing out what it's like converting the .proto file into TS. I am successfully able to generate some of the files, however, I am missing the TypeScript "Service" file.
I pretty much followed the instructions from the grpc_tools_node_protoc_ts site.
Setup a script to generate files for 1) the service and 2) the client model:
PROTOC_GEN_TS_PATH="./node_modules/.bin/protoc-gen-ts"
GRPC_TOOLS_NODE_PROTOC_PLUGIN="./node_modules/.bin/grpc_tools_node_protoc_plugin"
GRPC_TOOLS_NODE_PROTOC="./node_modules/.bin/grpc_tools_node_protoc"
OUT_DIR="./_protos_/proto/"
# JavaScript code generating
${GRPC_TOOLS_NODE_PROTOC} \
--plugin=protoc-gen-grpc="${GRPC_TOOLS_NODE_PROTOC_PLUGIN}" \
--js_out=import_style=commonjs,binary:"${OUT_DIR}" \
--grpc_out="${OUT_DIR}" \
-I "${OUT_DIR}" \
"${OUT_DIR}"/*.proto
${GRPC_TOOLS_NODE_PROTOC} \
--plugin=protoc-gen-ts="${PROTOC_GEN_TS_PATH}" \
--ts_out="${OUT_DIR}" \
-I "${OUT_DIR}" \
"${OUT_DIR}"/*.proto
What I get on the output is missing the *_grpc_pb.d.ts. I am under the impression I need this? 🤷🏻♂️
I have also tried adding the service option to the flag:
--ts_out="service=grpc-web:${OUT_DIR}" \
This now generates a *_pb_service.d.ts output file, still without the *_grpc_pb.d.ts file. I was reading the docs more and am thinking this service=grpc-web is actually the option I need since we're not running a node server.
Does this seem right? This is what I have now:
# Note the ts_out flag "service=grpc-node":
# This does generate the *_grpc_pb.d.ts but not the service files
protoc \
--plugin="protoc-gen-ts=${PROTOC_GEN_TS_PATH}" \
--plugin=protoc-gen-grpc=${GRPC_TOOLS_NODE_PROTOC_PLUGIN} \
--js_out="import_style=commonjs,binary:${OUT_DIR}" \
--ts_out="service=grpc-node:${OUT_DIR}" \
--grpc_out="${OUT_DIR}" \
-I "${OUT_DIR}" \
"${OUT_DIR}"/*.proto
# Note the ts_out flag "service=grpc-web":
# This does generate the service files, but not the *_grpc_pb.d.ts file
protoc \
--plugin="protoc-gen-ts=${PROTOC_GEN_TS_PATH}" \
--plugin=protoc-gen-grpc=${GRPC_TOOLS_NODE_PROTOC_PLUGIN} \
--js_out="import_style=commonjs,binary:${OUT_DIR}" \
--ts_out="service=grpc-web:${OUT_DIR}" \
--grpc_out="${OUT_DIR}" \
-I "${OUT_DIR}" \
"${OUT_DIR}"/*.proto
I try to compile Qt project with CentOS.
This question describe what I have done in detail and
I want to do with another glibc libraries /users/my/lib64/ (I can't update /lib64/) by referring to this.
This is the compile out put:
g++ ./main.o ./moc_widget.o ./widget.o \
-o ./test -Wl,--rpath=/users/my/lib64 \
-Wl,--rpath=/users/my/Qt/5.9.1/gcc_64/lib \
-Wl,--dynamic-linker=/users/my/lib64/libc.so.6 \
-Wl,--dynamic-linker=/users/my/lib64/libz.so.1 \
-L/users/my/Qt/5.9.1/gcc_64/lib -lQt5Widgets \
-lQt5Gui -lQt5Core -lGL -lpthread -lglib-2.0 -lrt -lX11 \
-I/users/my/test/2 \
-I/users/my/Qt/5.9.1/gcc_64/include \
-I/users/my/Qt/5.9.1/gcc_64/include/QtWidgets \
-I/users/my/Qt/5.9.1/gcc_64/include/QtCore \
-I/users/my/Qt/5.9.1/gcc_64/include/QtGui
.pro file :
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = test
TEMPLATE = app
DEFINES += QT_DEPRECATED_WARNINGS
CONFIG += qt
SOURCES += \
main.cpp \
widget.cpp
HEADERS += \
widget.h
FORMS += \
widget.ui
gcc version : 6.1.0
But the error:
/users/my/Qt/5.9.1/gcc_64/lib/libQt5Core.so: undefined reference to `clock_gettime#GLIBC_2.17'
/users/my/Qt/5.9.1/gcc_64/lib/libQt5Widgets.so: undefined reference to `memcpy#GLIBC_2.14'
collect2 ld returned exit 1 status
How to solve it ?
g++ ./main.o ./moc_widget.o ./widget.o \
-o ./test -Wl,--rpath=/users/my/lib64 \
-Wl,--rpath=/users/my/Qt/5.9.1/gcc_64/lib \
-Wl,--dynamic-linker=/users/my/lib64/libc.so.6 \
-Wl,--dynamic-linker=/users/my/lib64/libz.so.1 \
-L/users/my/Qt/5.9.1/gcc_64/lib -lQt5Widgets \
-lQt5Gui -lQt5Core -lGL -lpthread -lglib-2.0 -lrt -lX11 \
-I...
This command line is completely bogus (you didn't understand previous answer): there can only be one dynamic linker, and it should be /users/my/lib64/ld-linux-x86-64.so.2, and not libz.so.1. By using multiple --dynamic-linker=... flags, you are simply replacing previous (incorrect) setting with a new (also incorrect) one.
It's also bogus because specifying -I... flags on the link line without any sources is pointless.
If this command succeeded, you'd end up with an executable that would simply crash immediately, because libz.so.1 is not a dynamic linker.
Now, your link fails because you are performing the link on the wrong system. You need to link on the original system (the one where you successfully linked your binary earlier, and the one which has GLIBC 2.17 or later). And then move the linked executable to your target system.
On the original system, your link command should look something like this:
g++ main.o moc_widget.o widget.o -o test \
-Wl,-rpath=/users/my/lib64 \
-Wl,--dynamic-linker=/users/my/lib64/ld-linux-x86-64.so.2 \
-L...
The two lines I indented above should be the only change from your original successful link command.