Barrys News — Posts tagged "oe"

This blog supports posting in different categories, for example "oe", "easy" and "light". In theory, a post can be to more than one category, but I have never tested that. The OpenEmbedded "oe" project is intertwined with EasyOS "easy", so I often post OpenEmbedded news to the "easy" category. But that is a problem if you go to the "oe" URL, you won't see those posts:

https://bkhome.org/news/tag_oe.html

So, this post is to the "oe" category, with links to recent OpenEmbedded posts.

As I have pretty much decided to stay with the Dunfell-series for EasyOS, packages compiled in OpenEmbedded, have been through the exercise of updating and improving the OE build. These are the relevant posts over the last few days:

Statically linked packages with musl in OpenEmbedded — August 28, 2021
OpenEmbedded Dunfell aarch64 rebuild — August 27, 2021
807 packages compiled in OpenEmbedded for EasyOS — August 26, 2021
OpenEmbedded Dunfell updated rebuild — August 26, 2021

The latest OE-Dunfell project tarball is 'dunfell-20210828.tar.gz', uploaded here:

http://distro.ibiblio.org/easyos/project/oe/dunfell/

There are some large packages that are not compiled in OE, such as SeaMonkey. Reason, they are very cross-compiler unfriendly. I am planning to enhance woofQ with automated package compiler functionality in a running EasyOS.

Tags: oe

Inkscape compiled in OpenEmbedded

April 10, 2021 — BarryK

As already posted, I have recompiled everything in OE:

https://bkhome.org/news/202104/dunfell-recompile-commencing-in-openembedded.html

Also added 'pngoverlay-cairo':

https://bkhome.org/news/202104/pngoverlay-cairo-utility-now-in-woofq.html

Cross-compiling can be a challenge with some packages, and some of the big ones, such as SeaMonkey, LibreOffice and Inkscape, I have compiled in a running EasyOS (with the "devx" SFS loaded).

I have previously compiled LibreOffice in OE, see the Pyro series. But it was a lot of work.

Today I have imported Inkscape into OE. Had to import these dependencies into OE:

double-conversion potrace gdl

Then inkscape compiled, no issues. Good, I congratulate the developers on a well-behaved build. It is version 1.0.2.

My latest OE, based on the Dunfell release, is available as a tarball. It is really just the Dunfell release of OE with my "meta-quirky" layer. The tarball has some documentation. Available here:

http://distro.ibiblio.org/easyos/project/oe/dunfell/dunfell-20210410.tar.gz

...there is no git repo, just these tarballs, that are snapshots of my local system. My host OS is EasyOS Dunfell-series 2.6.2 x86_64, with "devx" loaded. You need a partition with at least 350GB free -- my build was done on a new 1TB SATA SSD (connected via USB3), and so far using 326GB. If I was to do another build, for a different target, say i686, then the used storage would jump way up -- so good to have 1TB drive.

Tags: oe

Fixed compile of libvdpau-va-gl in OE

January 24, 2021 — BarryK

I posted yesterday about the problem in OpenEmbedded when the compile of a package requires execution of a binary:

https://bkhome.org/news/202101/fixed-compile-of-samba-without-krb5-in-oe.html

This problem does not occur if the build-architecture and target-architectures are the same. The problem occurs with a cross-compile.

Today I had the same problem, with package 'libvdpau-va-gl'. I had previously compiled this in OE, but now the build-arch is x86_64 and the target-arch is aarch64.

So, I used the same trick as with samba, of using pre-compiled binaries, in this case it is just the one binary, 'shader-bundle-tool'. The package uses cmake and ninja, and my knowledge of these is minimal.

This is the recipe meta-quirky/recipes-quirky/libvdpau-va-gl/libvdpau-va-gl_0.4.2.bb:

# Recipe created by recipetool
# recipetool create -o libvdpau-va-gl_0.4.2.bb https://github.com/i-rinat/libvdpau-va-gl/releases/download/v0.4.2/libvdpau-va-gl-0.4.2.tar.gz

# 20210121 PR_NUM is defined in local.conf...
#PR = "r${@int(PR_NUM) + 1}"

LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5a9126e7f56a0cf3247050de7f10d0f4"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#20210124 wants to run a binary:
#| /bin/sh: /mnt/sda1/nvme/oe-builds/oe-quirky/build-aarch64/tmp/work/aarch64-poky-linux/libvdpau-va-gl/0.4.2-r1/build/glsl/shader-bundle-tool: cannot execute binary file: Exec format error

SRC_URI = "https://github.com/i-rinat/libvdpau-va-gl/releases/download/v${PV}/libvdpau-va-gl-${PV}.tar.gz \
  file://${BUILD_ARCH}/shader-bundle-tool"

SRC_URI[md5sum] = "8db21dcfd5cd14c6ec51b992e20369dc"
SRC_URI[sha256sum] = "7d9121540658eb0244859e63da171ca3869e784afbeaf202f44471275c784af4"

DEPENDS = "libx11 ffmpeg libvdpau libva mesa xserver-xorg"

inherit cmake pkgconfig

EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"

do_compile_prepend() {
 mkdir -p ${B}/glsl/
 cp -a -f ${WORKDIR}/${BUILD_ARCH}/shader-bundle-tool ${B}/glsl
 touch -d '+1 hour' ${B}/glsl/shader-bundle-tool
 #fool ninja not to overwrite shader-bundle-tool...
 sed -i -e 's%TARGET_FILE = glsl/shader-bundle-tool%TARGET_FILE = glsl/shader-bundle-toolXXX%' ${B}/build.ninja 
}

FILES_${PN} += "${libdir}/vdpau"

INSANE_SKIP_${PN} += "dev-so"

HOMEPAGE = "https://github.com/i-rinat/libvdpau-va-gl"
SUMMARY = "VDPAU driver with OpenGL/VAAPI backend"

Notice the line "touch -d '+1 hour' ${B}/glsl/shader-bundle-tool" -- I thought that setting the modify date ahead would prevent ninja from recompiling it, but that didn't work. Ninja does not work like make.

Instead, I found the 'build.ninja' file, which specified the name of the compiled file, so I just changed that from 'shader-bundle-tool' to 'shader-bundle-toolXXX'. Great, worked, left the pre-compiled binary intact.

The recipe works. I have added this package to the Pi4 package-list, although I don't know what use it will be. By setting VDPAU_DRIVER=va_gl, it causes VDPAU to use the GL backend, but I don't now much about VDPAU either.

Here is the libvdpau-va-gl project page:

https://github.com/i-rinat/libvdpau-va-gl

Only including this in the next Pi4 build as something extra to play with.

Tags: oe

Fixed compile of Samba without krb5 in OE

January 22, 2021 — BarryK

Yesterday I posted about improvements compiling in OpenEmbedded:

https://bkhome.org/news/202101/tweaks-for-openembedded-dunfell.html

EasyOS on the Pi4 does not have samba, as compile failed in OE. Yes, I could compile it in a running EasyOS on the Pi4, but would rather fix it in OE.

I have a 'samba_%.bbappend' file, the main objective being to remove the 'pam' and 'krb5' dependencies. I worked on this recipe this morning. The problem is that instead of 'krb5', the internal 'heimdahl' is used, and this compiles two binaries, that are then executed during compile.

The problem is that the binaries are compiled for the target system, in this case aarch64, whereas the build system is x86_64, so the binaries cannot run.

OE does have a mechanism to handle this. It is possible to compile 'samba-native', that is, samba compiled to run on the build-system, and then use the two binaries from that when compile 'samba'.

Fine, except that exactly how to do this is very poorly documented. The official documentation is very vague. A couple of years ago, I bought a book, "Embedded Linux Systems with the Yocto Project", but found that it also said hardly anything about this. I consider this to be an important topic, yet it seems that many OE experts don't know much about it either.

Perhaps it is explained somewhere, and I have just overlooked it.

Anyway, when I hit this problem, I just use pre-compiled binaries, by compiling the package separately on my build-system.

In the case of samba, that is what Uri has done:

http://samba.2283325.n4.nabble.com/Samba4-4-5-cross-compilation-for-PowerPC-td4710972.html

...not on OE, but I can apply the same principle. This is my 'samba_%.bbappend':

#heimdahl compiles these and want to run them during compile...
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = "\
  file://${BUILD_ARCH}/asn1_compile \
  file://${BUILD_ARCH}/compile_et"

DEPENDS = "readline virtual/libiconv zlib popt libtalloc libtdb libtevent libldb libaio libtasn1 jansson libbsd gpgme acl gnutls libarchive openldap"

REQUIRED_DISTRO_FEATURES = ""

SYSTEMD_PACKAGES = ""
SYSTEMD_SERVICE_${PN}-base = ""
SYSTEMD_SERVICE_${PN}-ad-dc = ""
SYSTEMD_SERVICE_winbind = ""
SYSTEMD_AUTO_ENABLE_${PN}-ad-dc = ""

PACKAGECONFIG = ""

EXTRA_OECONF = "--enable-fhs \
                 --with-piddir=/run \
                 --with-sockets-dir=/run/samba \
                 --with-modulesdir=${libdir}/samba \
                 --with-lockdir=${localstatedir}/lib/samba \
                 --with-cachedir=${localstatedir}/lib/samba \
                 --disable-rpath-install \
                 ${@oe.utils.conditional('TARGET_ARCH', 'x86_64', '', '--disable-glusterfs', d)} \
                 --with-cluster-support \
                 --with-profiling-data \
                 --with-libiconv=${STAGING_DIR_HOST}${prefix} \
                 --without-pam --without-sendfile-support \
                 --without-ad-dc  --without-ntvfs-fileserver  --nopyc --nopyo \
                 --without-fam --without-lttng --without-systemd --disable-avahi \
                 --enable-cups --with-acl-support --with-automount --with-quotas \
                 --with-syslog --with-ldap --enable-gnutls --with-gpgme --with-libbsd \
                 --with-libarchive --without-valgrind \
                 --bundled-libraries=!asn1_compile,!compile_et"

RDEPENDS_${PN}-ad-dc = ""

# ref: http://samba.2283325.n4.nabble.com/Samba4-4-5-cross-compilation-for-PowerPC-td4710972.html
export USING_SYSTEM_ASN1_COMPILE = "1"
export ASN1_COMPILE = "${WORKDIR}/${BUILD_ARCH}/asn1_compile"
export USING_SYSTEM_COMPILE_ET = "1"
export COMPILE_ET = "${WORKDIR}/${BUILD_ARCH}/compile_et"

ERROR_QA_remove = "file-rdeps"
WARN_QA_remove = "file-rdeps"

As my build-system is EasyOS x86_64 on a PC, I placed those two 'asn1_compile' and 'compile_et' into meta-quirky/recipes-connectivity/samba/samba/x86_64. I also grabbed the two that were compiled in OE and put them into samba/samba/aarch64. The 'samba_%.bbappend' is in meta-quirky/recipes-connectivity/samba.

Note, 'meta-quirky' is my layer in OE, with all of my customizations and extra packages.

Good, it compiled and installed.

Just a little detail: in OE, HOST_ARCH is "aarch64", that is, the target architecture. Not, as you might think, the build system architecture. We often use the term "host system", but that is misleading with OE, so I use the term "build system".

Tags: oe