[yocto] Using extensible SDK with multilib
Hello everyone, Short version: I have an 64 bit Yocto Raspberry build with a piece of 32 bit software with multilib. The goal is now to be able to use the eSDK to build 32 bit software for that system. After building and installing the eSDK there are even two files environment-setup-aarch64-poky-linux and environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi. After sourcing the 32bit armv7ve environment file, devtool is still building my software as 64 bit. Why doesn't it work? Long version: The multilib definition in my local config looks like this: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7ve" IMAGE_INSTALL_append_raspberrypi3-64 = " lib32-software-dummy" The software-dummy "hello world" project builds fine in 32 bit. Now on to the eSDK: The environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi actually didn't work out of the box, I needed to add the bottom of environment-setup-aarch64-poky-linux to environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi, so devtool is found. This part was missing from the armv7ve environment file: . /workdir/sdk/rpi/buildtools/environment-setup* export OE_SKIP_SDK_CHECK=1 export DEPLOY_DIR_IMAGE=/workdir/sdk/rpi/tmp/deploy/images/raspberrypi3-64 export PATH=/workdir/sdk/rpi/sysroots/x86_64-pokysdk-linux/usr/bin:$PATH printf 'SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. ' (which bitbake > /dev/null 2>&1 && echo 'WARNING: attempting to use the extensible SDK in an environment set up to run bitbake - this may lead to unexpected results. Please source this script in a new shell session instead.') || true Another thing I noticed that SDKTARGETSYSROOT in both files point to /workdir/sdk/rpi/tmp/sysroots/raspberrypi3-64 which is maybe not correct. Also not very sure about DEPLOY_DIR_IMAGE. Eg. in environment-setup-aarch64-poky-linux we have: export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" … export ARCH=arm64 export CROSS_COMPILE=aarch64-poky-linux- while in environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi: export CC="arm-pokymllib32-linux-gnueabi-gcc -march=armv7ve -mfpu=vfp -mfloat-abi=softfp --sysroot=$SDKTARGETSYSROOT" export CXX="arm-pokymllib32-linux-gnueabi-g++ -march=armv7ve -mfpu=vfp -mfloat-abi=softfp --sysroot=$SDKTARGETSYSROOT" … export ARCH=arm export CROSS_COMPILE=arm-pokymllib32-linux-gnueabi- After sourcing the armv7ve environment file, building the software I added with devtool, it's still building in 64 bit. Looking at the run.do_install logfile I see this: export AR="aarch64-poky-linux-ar" export AS="aarch64-poky-linux-as " … export CC="aarch64-poky-linux-gcc -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/workdir/sdk/rpi/tmp/work/aarch64-poky-linux/cmake-test/1.0-r0/recipe-sysroot" … export CCLD="aarch64-poky-linux-gcc -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/workdir/sdk/rpi/tmp/work/aarch64-poky-linux/cmake-test/1.0-r0/recipe-sysroot" for some reason it's all 64 bit in there and I don't know where this comes from. The armv7ve environment file also has /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/arm-pokymllib32-linux-gnueabi in it's PATH, where the 32 bit compilers seem to live. The only way I found to build my software is to build a little script that calls bitbake directly or to add IMAGE_INSTALL_append_raspberrypi3-64 = " lib32-cmake-test" to the local.config and build the image with devtool. Both are not nice solutions. Thank you for any help! Regards, - Michael -- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK: getting error "xmlcatalog: not found" installing SDK
Hello everyone,
I was able to workaround this issue:
In `conf/bblayers.conf` I put my custom layer ontop of the `meta` layer. Since
classes seem to ignore the priority set by the layer config. Then I copied the
`classes/xmlcatalog.bbclass` class to my layer and in the file I changed
`xmlcatalog` to `${bindir}/xmlcatalog`.
I'm still not sure if this an error specific to my setup or a general issue
which should be fixed. Also I was hoping there is a better solution since
changes to the original `classes/xmlcatalog.bbclass` will always be overridden.
Regards,
- Michael
--
bai...@tau-tec.com wrote on 30.07.2019 16:32:
> Hello,
>
> after updating to warrior 2.7.1 from thud and trying to install the
> Extensible
> SDK again I'm getting the following error:
>
> ```
> ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a
> python
> function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:do_build_native_sysroot(d)
> 0003:
> File:
> '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb',
> lineno: 23, function: do_build_native_sysroot
> 0019:
> 0020:python do_build_native_sysroot () {
> 0021: targetsysroot = d.getVar("STANDALONE_SYSROOT")
> 0022: nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
> *** 0023: staging_populate_sysroot_dir(targetsysroot, nativesysroot,
> True, d)
> 0024:}
> 0025:do_build_native_sysroot[cleandirs] =
> "${STANDALONE_SYSROOT_NATIVE}"
> 0026:do_build_native_sysroot[nostamp] = "1"
> 0027:addtask do_build_native_sysroot before do_build
> File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno:
> 235,
> function: staging_populate_sysroot_dir
> 0231: continue
> 0232:
> 0233: staging_processfixme(fixme, targetdir, targetsysroot,
> nativesysroot, d)
> 0234: for p in postinsts:
> *** 0235: subprocess.check_output(p, shell=True,
> stderr=subprocess.STDOUT)
> 0236:
> 0237:#
> 0238:# Manifests here are complicated. The main sysroot area has the
> unpacked sstate
> 0239:# which us unrelocated and tracked by the main sstate manifests.
> Each
> recipe
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 395, function: check_output
> 0391: # empty string. That is maintained here for backwards
> compatibility.
> 0392: kwargs['input'] = '' if kwargs.get('universal_newlines', False)
> else b''
> 0393:
> 0394: return run(*popenargs, stdout=PIPE, timeout=timeout,
> check=True,
> *** 0395: **kwargs).stdout
> 0396:
> 0397:
> 0398:class CompletedProcess(object):
> 0399: """A process that has finished running.
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 487, function: run
> 0483: raise
> 0484: retcode = process.poll()
> 0485: if check and retcode:
> 0486: raise CalledProcessError(retcode, process.args,
> *** 0487: output=stdout, stderr=stderr)
> 0488: return CompletedProcess(process.args, retcode, stdout, stderr)
> 0489:
> 0490:
> 0491:def list2cmdline(seq):
> Exception: subprocess.CalledProcessError: Command
> '/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
> returned non-zero exit status 127.
>
> Subprocess output:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 5:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 8:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> ```
>
> I believe the problem is that in the
> `postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not
> an
> absolute path and thus not found.
> This can be traced to the new
> `layers/poky/meta/classes/xmlcatalog.bbclass`. I
> tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog`
> there,
> but even after cleaning the `docbook-xsl-stylesheets` recipe this change
> had no
> effect. I'm not sure if this class is cached somewhere else or something.
>
> Can someone help me getting the SDK to work again, and maybe this is
> general
> thing with needs to be fixed?
>
>
> Thank you.
>
> Regards,
>
> - Michael
> --
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listi
Re: [yocto] Yocto repos for NXP referent platform MCIMXABASEV1 also called SABRE platform?
On Thu, Aug 8, 2019 at 11:20 PM Zoran Stojsavljevic wrote: > > Hello to all, > > I am trying to find out some recent yocto repo, which contains YOCTO > reference repo for the following NXP board: > MCIMXABASEV1 also called SABRE platform. > > Here is one repo I found reading this document... But this is too outdated! > > http://events17.linuxfoundation.org/sites/events/files/slides/AGLAMM_How%20we%20Run%20AGL%20on%20i.MX%20processors_tkobayashi_25FEB16%20rev.D.pdf > > Does anybody have some other repos/suggestions in mind for such a > board? Please, come forward if yes... > I would say look at http://layers.openembedded.org/layerindex/branch/master/machines/?q=sabre&search=1 > Thank you, > Zoran > ___ > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior
On Fri, 2 Aug 2019 at 21:20, Ryan Harkin wrote: > Hi Carsten, > > Thanks for your help. > > On Fri, 2 Aug 2019 at 20:42, Stelling2 Carsten < > carsten.stelli...@goerlitz.com> wrote: > >> Hi Ryan, >> >> >> >> Regarding to timesyncd, have a look at >> https://wiki.archlinux.org/index.php/systemd-timesyncd, especially the >> section >> >> “Note: The service writes to a local file /var/lib/systemd/timesync/clock >> with every synchronization. >> >> This location is hard-coded and cannot be changed. This may be >> problematic for running off >> >> read-only root partition or trying to minimize writes to an SD card.” >> > > Yes, this looks like it is my problem. I experimented with timesync, and > by making /var/lib and a few other places writable, I'm able to start it > manually, but not via systemd, which I think is experiencing other issues > with the read-only rootfs. > > >> >> See also https://github.com/systemd/systemd/issues/5610 for your problem >> with systemd-resolved. >> >> According to this, /var, /var/tmp, /run, and /tmp should be writable. >> > I think the problem is not Yocto specific, but possibly I overlook >> something. >> > > Again, I think you're right. I need to have these areas writable from > boot. But I don't know how. > > I suppose my problem is that these areas used to be writable when I was > using Sumo, but moving to Warrior has caused something to change. I'm > wondering what extra steps I need to do in Warrior to ensure that all these > things are mounted with tmpfs as before. I expect my Sumo recipes worked > through luck more than design, and now something has changed, I need to > improve them. > > It is rather difficult to work out what the relevant changes are. > I still don't know what has changed between Sumo and Warrior so it works on Sumo, but not on Warrior. However, I tried a different board (WaRP7) with Warrior, and read-only works as expected. I tried removing the read-only flag from my malfunctioning board setup, and I still have the problems. Of course, the quirky system I'm fixing boots in a more complex way that WaRP7. There is a service that boots at startup, with a script to switch-root from initramfs to an UBI partition. The UBI partition is being mounted read-only in the switch-root script. If I change this to read-write, everything works. I think one fix for me is to have my script manually mount /tmp, /var/volatile, and so on, as tmpfs. It doesn't explain what's changed, however. Either way, the fault appears to be in my environment, and Sumo possibly worked with luck. Regards, Ryan. > Kind regards, > Ryan. > > >> >> Best regards, >> >> >> >> Carsten >> >> >> >> *Von:* yocto-boun...@yoctoproject.org [mailto: >> yocto-boun...@yoctoproject.org] *Im Auftrag von *Ryan Harkin >> *Gesendet:* Freitag, 2. August 2019 13:09 >> *An:* yocto@yoctoproject.org >> *Cc:* openembedded >> *Betreff:* [yocto] /var/volatile not mounted as tmpfs on read-only >> rootfs when migrating to Warrior >> >> >> >> Hi, >> >> >> >> I have a working system based on Sumo. The system boots with a read-only >> rootfs, then applies are read-write overlay for /etc. >> >> >> >> When I migrate to Warrior, systemd-resolved fails to start. If I mount >> the same rootfs via NFS, it starts and works fine. systemd-timesyncd is >> also failing, but I haven't looked into that yet. It also works fine on the >> NFS mounted system. >> >> >> >> The resolve problem seems to be caused by two things: >> >> - /var/volatile is read-only >> >> - /run/systemd/resolve has the wrong ownership >> >> drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 >> resolve/ >> >> I think this permissions problem may be a result of the >> /var/volatile mounting >> >> problems; it looks fine on the NFS mounted system. >> >> >> >> If I manually mount /var/volatile (it's in fstab) and change the >> ownership on /run/systemd/resolve, the service starts just fine. >> >> >> >> I also notice that /tmp is not mounted at all, which may be related. >> >> >> >> Here are the various tmp mount points on my read-only rootfs: >> >> >> >> $ mount | grep tmp >> >> devtmpfs on /dev type devtmpfs >> (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) >> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) >> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) >> tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) >> overlay on /etc type overlay >> (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) >> tmpfs on /run/user/0 type tmpfs >> (rw,nosuid,nodev,relatime,size=23840k,mode=700) >> >> On the NFS mounted system, I see these: >> >> >> >> $ mount | grep tmp >> devtmpfs on /dev type devtmpfs >> (rw,relatime,size=118180k,nr_inodes=29545,mode=755) >> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) >> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) >> tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) >> tmpfs on /tmp type tmpfs (rw,nosuid,nod
[yocto] [meta-selinux][PATCH] libselinux: fix build with glibc 2.30
Fix build error:
procattr.c:27:14: error: static declaration of 'gettid' follows
non-static declaration
27 | static pid_t gettid(void)
| ^~
In file included from
/buildarea/build/tmp/work/core2-64-poky-linux/libselinux/2.8-r0/recipe-sysroot/usr/include/unistd.h:1170,
from procattr.c:2:
/buildarea/build/tmp/work/core2-64-poky-linux/libselinux/2.8-r0/recipe-sysroot/usr/include/bits/unistd_ext.h:34:16:
note: previous declaration of 'gettid' was here
34 | extern __pid_t gettid (void) __THROW;
|^~
Signed-off-by: Yi Zhao
---
...Do-not-define-gettid-if-glibc-2.30-is-use.patch | 60 ++
recipes-security/selinux/libselinux_2.8.bb | 1 +
2 files changed, 61 insertions(+)
create mode 100644
recipes-security/selinux/libselinux/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
diff --git
a/recipes-security/selinux/libselinux/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
b/recipes-security/selinux/libselinux/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
new file mode 100644
index 000..fc3e37e
--- /dev/null
+++
b/recipes-security/selinux/libselinux/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
@@ -0,0 +1,60 @@
+From 2c672b4cc39fbddb6faec2c7434832058f339d59 Mon Sep 17 00:00:00 2001
+From: Petr Lautrbach
+Date: Mon, 11 Mar 2019 16:00:41 +0100
+Subject: [PATCH] libselinux: Do not define gettid() if glibc >= 2.30 is used
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Since version 2.30 glibc implements gettid() system call wrapper, see
+https://sourceware.org/bugzilla/show_bug.cgi?id=6399
+
+Fixes:
+cc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-I../include -D_GNU_SOURCE -DNO_ANDROID_BACKEND -c -o procattr.o procattr.c
+procattr.c:28:14: error: static declaration of ‘gettid’ follows non-static
declaration
+ 28 | static pid_t gettid(void)
+ | ^~
+In file included from /usr/include/unistd.h:1170,
+ from procattr.c:2:
+/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’
was here
+ 34 | extern __pid_t gettid (void) __THROW;
+ |^~
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/selinux/commit/707e4b8610733b5c9eaac0f00239778f3edb23c2]
+
+Signed-off-by: Petr Lautrbach
+Signed-off-by: Yi Zhao
+---
+ src/procattr.c | 15 +--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+diff --git a/src/procattr.c b/src/procattr.c
+index 8bf8432..3c7b87f 100644
+--- a/src/procattr.c
b/src/procattr.c
+@@ -22,8 +22,19 @@ static pthread_key_t destructor_key;
+ static int destructor_key_initialized = 0;
+ static __thread char destructor_initialized;
+
+-#ifndef __BIONIC__
+-/* Bionic declares this in unistd.h and has a definition for it */
++/* Bionic and glibc >= 2.30 declare gettid() system call wrapper in unistd.h
and
++ * has a definition for it */
++#ifdef __BIONIC__
++ #define OVERRIDE_GETTID 0
++#elif !defined(__GLIBC_PREREQ)
++ #define OVERRIDE_GETTID 1
++#elif !__GLIBC_PREREQ(2,30)
++ #define OVERRIDE_GETTID 1
++#else
++ #define OVERRIDE_GETTID 0
++#endif
++
++#if OVERRIDE_GETTID
+ static pid_t gettid(void)
+ {
+ return syscall(__NR_gettid);
+--
+2.7.4
+
diff --git a/recipes-security/selinux/libselinux_2.8.bb
b/recipes-security/selinux/libselinux_2.8.bb
index 5de4607..7545967 100644
--- a/recipes-security/selinux/libselinux_2.8.bb
+++ b/recipes-security/selinux/libselinux_2.8.bb
@@ -12,4 +12,5 @@ SRC_URI += "\
file://libselinux-make-SOCK_CLOEXEC-optional.patch \
file://libselinux-define-FD_CLOEXEC-as-necessary.patch \
file://0001-src-Makefile-fix-includedir-in-libselinux.pc.patch \
+file://0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
\
"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to create a service only startes at shutdown process?
Hi ChenQi, Thanks for the help, I tried following service, it did not work, the systemd complains bad unit [Unit] Description=Application Shutdown Service Before=multi-user.target [Service] Type=oneshot ExecStart= ExecStop=/usr/sbin/app_cleanup.sh [Install] WantedBy=multi-user.target >> Most of the services are started in boot, how can I have create a >> service only to be active in shutdown (not in boot) to clean up? >> >> Thank you. >> >> Kind regards, >> >> - jh > > Make use of ExecStop, leave ExecStart to be empty. I tried it: [Unit] Description=Application Shutdown Service Before=multi-user.target [Service] Type=oneshot ExecStart= ExecStop=/usr/sbin/app_cleanup.sh [Install] WantedBy=multi-user.target There were errors: Loaded: bad-setting (Reason: Unit myclean.service has a bad unit file set) What I could be missing here? Thank you very much. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PR Service multibranch project
Hi, I'm looking at enabling PR Service to auto increment some recipe revision. On a build server I exposed sstate and downloads folder to use that server as a mirror. So I'm thinking of putting PR service there. Few things are unclear to me after reading the doc: We use repotool to manage our branch configuration for different projects. These different projects share common repositories Do I need to run an instance of PR server per project or is the database shared with multiple projects? Do I understand correctly that if I turn ON buildhistory, I would be able to switch my layers branches without bumping the revision if it already exists in the database? Is the revision bumping MACHINE dependent? Thanks, -Damien -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
