Re: [yocto] Is Yocto the right fit for my project?
On Wed, Nov 20, 2019 at 01:12:52PM +, Richard Barrass wrote: > Hello, > > I am a lead engineer on project where we run a well-known Linux distribution > on-top of a SBC (Intel Quad Pentium processor based) driving a 27" display. > We have a 32GB SSD to run from, which we partition with multiple EXT4 > partitions to help with potential corruption mitigation if the device is > switched off 'hard'. > > But, with the well-known Linux distribution comes a lot of things we don't > need, plus the potential ability to 'break' in to our application which is > running full-screen. > > We basically need > > QT 5.12 runtime (our application) > SSH > OpenVPN > Wifi > Ethernet > Modem (via Telit modem) > USB-ACM > USB-Memory stick > > Is this something I should be looking to the yocto project for, or should I > be looking at a more 'traditional' custom linux distro. > > The only other aspect, is that we have future plans to cost reduce the > application to be running on a Pi based, 10" display system ... > > Any thoughts and ideas would be appreciated. Sounds like yocto could fit to your needs well. My personal experiences summarized: Pros with yocto: * configuration of everything is possible * BSP support available for various SoC's and boards * optimization for size and disabling not-needed functionality is relatively easy * BSP, OS vendor and community support is available * licensing policies can be configured for the build, e.g. avoid GPLv3 * test tooling and infrastructure is provided, ptests and selftests, which can be reused for product specific ones * documentation is good, mega manual * fast moving and following latest open source component releases Cons with yocto: * steep learning curve with bitbake and yocto distro configuration * need to recompile everything * everything needs to be configured, defaults may not be available * long term support not available from community directly, yet at least, though OS vendors do provide this for a fee * BSP support quality varies and may conflict with non-HW specific SW parts * fast moving and following latest open source component releases Pros with well known Linux distros: * default configurations quite often work out of the box * no need to recompile everything * minimal BSP binaries usually available * long term support quite often available * large package collection enable fast prototyping * larger developer base compared to yocto Cons with well known Linux distros: * dependencies are complex and images larger than needed for product * recompiling and customizing large set of packages may be difficult * cross compiling may be trickier * BSP deliveries may be outdated * licensing policies may be hard to implement, e.g. avoid GPLv3 in product images * integrated test tooling may not be available In short I would say, with yocto you need to configure and optimize and figure out how to maintain. With well known Linux distro you will struggle to configure and optimize but long term maintenance will be covered by an LTS. "With enough thrust any pig will fly" :) Hope this helps, -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 09:39:32AM -0400, Patrick Doyle wrote: > I have a set of data files (cryptographic keys) that I would like to > share among several recipes in my build. They won't go into the > rootfs, but they will be used by multiple recipes that construct the > rootfs. So, to the best of my understanding, it seems like I should > put them in sysroot and somehow access them from there. One possibility is to provide these keys as host native tools and data to build of target recipes. This makes the files available in the build environment but does not expose them to target. Create a -native recipe which has and installs the files and use via DEPENDS to the -native recipe. Hope this helps, -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing HOST_CC_ARCH temporarily in recipe
Hi,
On Wed, Sep 18, 2019 at 11:26:29AM +0300, Damien LEFEVRE wrote:
> Hi,
>
> I have a package which requires to first build a x64 binary which is then
> used to compile the target platform binaries.
>
> The way I got away with it was to build that host binary from
> do_configure_prepend() and then continue with the build procedure.
>
> I recently upgraded to GCC7 + warrior and now building the host binary
> from do_configure_prepend fails due to this error:
> testCCompiler.c:1:0: error: bad value (armv8-a+crc) for -march= switch
>
> I figured that the arch switch (building for tegra) is defined
> in HOST_CC_ARCH as:
> -march=armv8-a+crc -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat
> -Wformat-security -Werror=format-security
>
> If I clear HOST_CC_ARCH in my recipe file, do_configure_prepend succeeds
> but of course the rest of the build will fail.
>
> So i'm trying to do something like this:
> do_configure_prepend(){
> export HOST_CC_ARCH_BACKUP="${HOST_CC_ARCH}"
> HOST_CC_ARCH=""
> echo "HOST_CC_ARCH before cmake: ${HOST_CC_ARCH}"
> CC="${BUILD_CC}" CXX="${BUILD_CXX}" CCFLAGS="${BUILD_CFLAGS}"
> CXXFLAGS="${BUILD_CPPFLAGS} -std=c++11" LDFLAGS="${BUILD_LDFLAGS}" cmake
> ${S}
> make
> HOST_CC_ARCH="${HOST_CC_ARCH_BACKUP}"
> }
>
> There I still get:
> HOST_CC_ARCH before cmake: -march=armv8-a+crc -fstack-protector-strong
> -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
>
> So HOST_CC_ARCH doesn't get updated.
>
> How can I temporarily reset HOST_CC_ARCH?
Only clean way to do this is to split the recipe into two parts:
* native for the build time tooling
* target for the target only build, which depends on the native build
time tooling
Everything else is a hack :)
Hope this helps,
-Mikko
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 1/2] meson-selinux.bbclass: fix meson flags for glib-2.0-native
Hi,
On Wed, Aug 28, 2019 at 01:19:17PM -0400, Joe MacDonald wrote:
> Hi Mikko,
>
> Is this specifically for warrior (or thud), maybe? The following commit
> explains the current logic:
>
> commit bb0c9c3abcb935e4b362eb57985e1ee7fec0bfe0
> Author: Yi Zhao
> Date: Wed Jun 12 15:53:20 2019 +0800
>
> glib-2.0: fix configure error for meson build
>
> In glib 2.60.x, it turns selinux into a meson feature. We should use
> '-Dselinux=enabled/disabled' rather than '-Dselinux=true/false' to
> enable/disable the feature.
>
> Add meso-enable-selinux.bbclass for this change and inherit it in
> glib-2.0 bbappend to fix the configure error.
>
> Signed-off-by: Yi Zhao
> Signed-off-by: Joe MacDonald
>
> and the second patch is already present in tree:
>
> commit 087fe5c8144c246c6361bd8bcbd1ffd9e9b675bb
> Author: Yi Zhao
> Date: Fri Aug 9 17:48:00 2019 +0800
>
> 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
> Signed-off-by: Joe MacDonald
>
> This is what my current work tree looks like, for reference:
>
> $ repo forall -p -c git log -1 --pretty=oneline
> project meta-openembedded/
> 2ebaa8df1257389161d0bee9e553c28f63e52005 python3-pyatspi: Add Dbus ATSPI
> recipe
>
> project meta-selinux/
> 154654a6fe12206a6b9ad6d8c36a4dbe672bcc46 selinux-python: Fix dependency for
> ntpath
>
> project yocto-mainline/
> ca2207f418b7847ffce4b8c53a5a442e5cf461d9 commands.py: fix typo
Hmm, good that same patches are already in master branch but I somehow got a
much older master branch state from remote
git://git.yoctoproject.org/meta-selinux
commit a917c322c120c05fc6746fc9aca38c27398ffb4a
Author: Yi Zhao
AuthorDate: Fri Apr 19 10:46:32 2019 +0800
Commit: Joe MacDonald
CommitDate: Tue Apr 23 11:12:57 2019 -0400
Was also checking master-next there.
Based on time stamps in .git/modules/meta-selinux/refs/remotes/upstream/ my
last fetch
was Aug 28 11:02 CET. Seems like the "libselinux: fix build with glibc 2.30"
was pushed to the server just after I had been checking for it:
commit 087fe5c8144c246c6361bd8bcbd1ffd9e9b675bb
Author: Yi Zhao
AuthorDate: Fri Aug 9 17:48:00 2019 +0800
Commit: Joe MacDonald
CommitDate: Wed Aug 28 10:26:52 2019 -0400
libselinux: fix build with glibc 2.30
Anyway, fixes are in and life continues :)
Thanks,
-Mikko
> -J.
>
> [[yocto] [meta-selinux][PATCH 1/2] meson-selinux.bbclass: fix meson flags for
> glib-2.0-native] On 19.08.28 (Wed 18:30) Mikko Rapeli wrote:
>
> > With latest poky master, glib-2.0-native fails to compile:
> >
> > | meson.build:1:0: ERROR: Value "false" for combo option is not one of the
> > choices. Possible choices are: "enabled",
> > "disabled", "auto".
> >
> > Thus use enabled and disabled when enabling and disabling flags
> > with meson. Now glib-2.0-native compiles again.
> >
> > Signed-off-by: Mikko Rapeli
> > ---
> > classes/meson-selinux.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/classes/meson-selinux.bbclass b/classes/meson-selinux.bbclass
> > index 77a763a..91c2a2b 100644
> > --- a/classes/meson-selinux.bbclass
> > +++ b/classes/meson-selinux.bbclass
> > @@ -1,4 +1,4 @@
> > inherit selinux
> >
> > PACKAGECONFIG_append = " ${@target_selinux(d)}"
> > -PACKAGECONFIG[selinux] = "-Dselinux=true,-Dselinux=false,libselinux,"
> > +PACKAGECONFIG[selinux] = "-Dselinux=enabled,-Dselinux=disabled,libselinux,"
> > --
> > 1.9.1
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> --
> -Joe MacDonald.
> :wq
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][warrior][master][PATCH] licenses: restore Elfutils-Exception from oe-core
On Wed, May 15, 2019 at 10:57:00AM +, Martin Jansa wrote:
> * it's still used by:
> recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ &
> Elfutils-Exception)"
> * was removed in oe-core with:
>
> http://git.openembedded.org/openembedded-core/commit/?id=88188807a6ac9bab738a69f6b4caba9ed092d78f
> * causing:
> do_rootfs: The license listed Elfutils-Exception was not in the licenses
> collected for recipe elfutils
Looks good!
Reviewed-by: Mikko Rapeli
> Signed-off-by: Martin Jansa
> ---
> conf/layer.conf | 2 ++
> licenses/Elfutils-Exception | 12
> 2 files changed, 14 insertions(+)
> create mode 100644 licenses/Elfutils-Exception
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 59f6a89..44c6712 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -15,3 +15,5 @@ LAYERVERSION_gplv2 = "1"
> LAYERDEPENDS_gplv2 = "core"
>
> LAYERSERIES_COMPAT_gplv2 = "warrior"
> +
> +LICENSE_PATH += "${LAYERDIR}/licenses"
> diff --git a/licenses/Elfutils-Exception b/licenses/Elfutils-Exception
> new file mode 100644
> index 000..627d769
> --- /dev/null
> +++ b/licenses/Elfutils-Exception
> @@ -0,0 +1,12 @@
> + This file describes the limits of the Exception under which you are
> allowed
> + to distribute Non-GPL Code in linked combination with Red Hat elfutils.
> + For the full text of the license, please see one of the header files
> + included with the source distribution or the file COPYING found in the
> + top level directory of the source.
> +
> + The Approved Interfaces are the functions declared in the files:
> +
> + libelf.h
> + libdw.h
> + libdwfl.h
> +
> --
> 2.17.1
>
> --
> ___
> 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] long time for starting sshd (wait for crng init done ?)
Hi, On Mon, May 13, 2019 at 01:07:45PM +0200, s...@gmx.li wrote: > >From yocto 2.5 to 2.7 I noticed a change in booting. The kernel stops for > >around 85 seconds. > It seems to me that starting sshd takes time until crng init is done. > In 2.5 it doesn't wait for that. How can I avoid that? > Maybe I have to add that I use a recipe that adds keys as rootfs is usually > r/o. Depends on your HW platform, kernel version etc, but one possible solution is installing rng-tools binary package which starts rngd at boot. See http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282021.html -Mikko > Another think I have observed (which is not clear to me): I don't get a > message from system message bus anymore. ??? > > Instead of it udevd complains about "specific group 'kvm' unknown. Looking > into source there are mentioned: > # The static_node is required on s390x and ppc (they are using MODULE_ALIAS) > So, can I safely ignore that (use ARM). > > > -- > ___ > 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] Changing IMAGE_NAME [yocto krogoth]
On Wed, Apr 10, 2019 at 11:47:42AM +0200, Mauro Ziliani wrote:
> Hi all.
>
> I need to change the default IMAGE_NAME of my image recipe.
>
> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
> and image (tar) with the name
>
> mysystem-image-1.0-.tar
>
>
> So I setup
>
> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
Should be:
IMAGE_NAME := "${IMAGE_BASENAME}-${PV}-${DATETIME}"
note the added $. I guess that's the bit which confuses bitbake. Been there,
done that
too :)
Hope this helps,
-Mikko
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering
On Fri, Apr 05, 2019 at 07:59:41AM +0100, richard.pur...@linuxfoundation.org wrote: > On Fri, 2019-04-05 at 06:54 +, mikko.rap...@bmw.de wrote: > > On Fri, Apr 05, 2019 at 07:46:00AM +0100, > > richard.pur...@linuxfoundation.org wrote: > > > On Fri, 2019-04-05 at 06:16 +, mikko.rap...@bmw.de wrote: > > > > On Thu, Apr 04, 2019 at 10:48:17PM +0100, Richard Purdie wrote: > > > > > On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote: > > > > > > As ptest-runner communicates with child processes via > > > > > > pipe2(), > > > > > > the corresponding channels are not attached to a pty. In that > > > > > > situation stdio facilities like printf() or fwrite() are > > > > > > fully > > > > > > buffered. If a ptest would use them, without bothering > > > > > > to fflush() the output, ptest-runner will only receive what > > > > > > was written by the child ptest process after a buffer gets > > > > > > filled. > > > > > > If the unit tests are proceeding slowly, this may mean that > > > > > > ptest-runner will erroneously timeout due to an apparent lack > > > > > > of > > > > > > 'signs of life' from the child process. > > > > > > > > > > > > stdbuf utility from coreutils adjusts the buffering to a > > > > > > line- > > > > > > buffered > > > > > > one, and so ptest-runner will get the lines as soon as they > > > > > > are > > > > > > written. > > > > > > > > > > > > Signed-off-by: Alexander Kanavin > > > > > > --- > > > > > > utils.c | 7 ++- > > > > > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > > > > > > > I'm a little torn on this. I noticed some of the run-ptest > > > > > scripts > > > > > use > > > > > "| sed -u" whilst the one you were seeing problems with uses "| > > > > > sed" > > > > > without -u. > > > > > > > > > > We may want to consider strongly recommending -u. I'm testing a > > > > > patch > > > > > with some tweaks like that in it... > > > > > > > > Please no. I'm running images without sed and using busybox sed > > > > instead, and that > > > > doesn't support -u. I'd rather be compatible with sed from > > > > busybox to > > > > keep changes > > > > to images minimal (e.g. install of additional packages) before > > > > executing ptests. > > > > > > The other alternative option being proposed is for ptest-runner to > > > depend on coreutils which is worse? > > > > GNU sed does not come from coreutils but from sed recipe. > > > > Your call in the end. I just provided my point of view. > > The original patch in this thread from Alex needs stdbuf which would > add a coreutils depends to ptest-runner for everything as I understand > it. Ok, that too then. Then all hope is lost so lets include sed there as well :) > > > I did test the -u option to sed in the openssh ptest runner and it > > > did > > > fix the problems we've been seeing. > > > > > > I'm open to other alternatives but the -u option to sed is looking > > > like > > > the best one we have right now. These bugs are making our testing > > > of > > > ptests effectively useless and unpredictable so this is a serious > > > issue... > > > > Understood. I hope you could also add 'set -eux' to all ptest shell > > scripts. Many of them seem to be missing shell script error handling > > and failures like providing -u to busybox sed may go unnoticed. > > Patches would be welcome to help clean up some of these scripts. I feel > like I'm fighting a lonely battle trying to get any of this to work at > times :( We're ramping up with ptests and will provide fixes back to upstream. > The good news is the automated monitoring of the ptest results should > catch problems like that as if a chunk of ptests "disappear", the new > testing should quickly highlight that. > > (We should improve the scripts, we just also have another way to spot > problems) All this work is very much appreciated here in downstream! Thanks you very much! -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering
On Fri, Apr 05, 2019 at 07:46:00AM +0100, richard.pur...@linuxfoundation.org wrote: > On Fri, 2019-04-05 at 06:16 +, mikko.rap...@bmw.de wrote: > > On Thu, Apr 04, 2019 at 10:48:17PM +0100, Richard Purdie wrote: > > > On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote: > > > > As ptest-runner communicates with child processes via pipe2(), > > > > the corresponding channels are not attached to a pty. In that > > > > situation stdio facilities like printf() or fwrite() are fully > > > > buffered. If a ptest would use them, without bothering > > > > to fflush() the output, ptest-runner will only receive what > > > > was written by the child ptest process after a buffer gets > > > > filled. > > > > If the unit tests are proceeding slowly, this may mean that > > > > ptest-runner will erroneously timeout due to an apparent lack of > > > > 'signs of life' from the child process. > > > > > > > > stdbuf utility from coreutils adjusts the buffering to a line- > > > > buffered > > > > one, and so ptest-runner will get the lines as soon as they are > > > > written. > > > > > > > > Signed-off-by: Alexander Kanavin > > > > --- > > > > utils.c | 7 ++- > > > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > > > I'm a little torn on this. I noticed some of the run-ptest scripts > > > use > > > "| sed -u" whilst the one you were seeing problems with uses "| > > > sed" > > > without -u. > > > > > > We may want to consider strongly recommending -u. I'm testing a > > > patch > > > with some tweaks like that in it... > > > > Please no. I'm running images without sed and using busybox sed > > instead, and that > > doesn't support -u. I'd rather be compatible with sed from busybox to > > keep changes > > to images minimal (e.g. install of additional packages) before > > executing ptests. > > The other alternative option being proposed is for ptest-runner to > depend on coreutils which is worse? GNU sed does not come from coreutils but from sed recipe. Your call in the end. I just provided my point of view. > I did test the -u option to sed in the openssh ptest runner and it did > fix the problems we've been seeing. > > I'm open to other alternatives but the -u option to sed is looking like > the best one we have right now. These bugs are making our testing of > ptests effectively useless and unpredictable so this is a serious > issue... Understood. I hope you could also add 'set -eux' to all ptest shell scripts. Many of them seem to be missing shell script error handling and failures like providing -u to busybox sed may go unnoticed. -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering
On Thu, Apr 04, 2019 at 10:48:17PM +0100, Richard Purdie wrote: > On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote: > > As ptest-runner communicates with child processes via pipe2(), > > the corresponding channels are not attached to a pty. In that > > situation stdio facilities like printf() or fwrite() are fully > > buffered. If a ptest would use them, without bothering > > to fflush() the output, ptest-runner will only receive what > > was written by the child ptest process after a buffer gets filled. > > If the unit tests are proceeding slowly, this may mean that > > ptest-runner will erroneously timeout due to an apparent lack of > > 'signs of life' from the child process. > > > > stdbuf utility from coreutils adjusts the buffering to a line- > > buffered > > one, and so ptest-runner will get the lines as soon as they are > > written. > > > > Signed-off-by: Alexander Kanavin > > --- > > utils.c | 7 ++- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > I'm a little torn on this. I noticed some of the run-ptest scripts use > "| sed -u" whilst the one you were seeing problems with uses "| sed" > without -u. > > We may want to consider strongly recommending -u. I'm testing a patch > with some tweaks like that in it... Please no. I'm running images without sed and using busybox sed instead, and that doesn't support -u. I'd rather be compatible with sed from busybox to keep changes to images minimal (e.g. install of additional packages) before executing ptests. -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
On Fri, Mar 29, 2019 at 09:50:20AM +0100, Dimitris Tassopoulos wrote:
> Hi all,
>
> I was thinking that the mail list shouldn't be only for problems and
> questions and that from time to time, it would be nice to see some guides,
> tutorials or success stories from people that follow the list.
>
> Anyway, a few days ago someone had an issue with one of the BSPs I'm
> maintaining and I wrote him a small guide on how to -try- to resolve future
> issues like that. Then I thought that I haven't found a small tutorial
> like this. Maybe it already exists, but nevertheless I haven't seen it.
> Of course, those things are in the documentation, but they are documented
> as individual tools (which is the correct thing to do), but it's not very
> clear how to use all those things together to perform more complex tasks.
>
> So, in my case the issue was that ofono was installed in the image and that
> needed to be removed. Probably a lot of you already know the answer but for
> me that I've never bothered with that I had to track it down how it got in
> there.
>
> Everything from now on assumes that you've setup up your bitbake environment
> of your build with whatever setup scripts you're using (e.g.
> *oe-init-build-env*)
>
> There are several ways to do introspection on an image. For example,
> let's say that you found a file in the in rootfs and you want to know which
> recipe added that file. Then you can use this command:
>
> oe-pkgdata-util find-path /usr/sbin/ofonod
>
>
> *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> `find-path` is pretty obvious what it does. This will return:
>
> ofono: /usr/sbin/ofonod
>
>
> So now you know that it's indeed the *ofono* recipe that adds this file.
> Next,
> you need how this did get in the image (probably some other dependency
> because you didn't). Then you can use the `-g` parameter with bitbake like
> this:
>
> bitbake -g allwinner-image
>
>
> This will create a file called `recipe-depends.dot`. This is a dot file that
> has all the dependencies in the image. You can use the same command to get
> the dependencies for a recipe, but now we care about the image.
>
> Next step is to search in that file, why that key is there. Why is `-w` and
> key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> and you
> run this command:
>
> oe-depends-dot -k ofono -w recipe-depends.dot
>
>
> This will return the recipe that has this as dependency.
>
>
> > Because: allwinner-image packagegroup-base
>
>
> That means that the key is there because of allwinner-image (this is the
> image
> recipe, but it can be any other image) and because the *allwinner-image*
> inherits the
> *packagegroup-base*. So this packagegroup is the guilty.
>
> Let's find this thing now. Get in the meta layer sources folder and run this
>
> find . | grep packagegroup-base
>
>
> This will return
>
> > ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
>
>
> Great. Open this file to an editor and find where is *ofono*. Gotcha, is in:
>
> RDEPENDS_packagegroup-base-3g
>
>
> Then it's the *packagegroup-base-3g* that does that. Probably that's a
> recipe
> or package group file, so you can run:
>
> find . | grep packagegroup-base-3g
>
>
> But you get nothing... Then probably this is declared somewhere a file with
> another name, so let's search inside the files in the poky layer:
>
> grep -nriI ackagegroup-base-3g
>
>
> And we get:
>
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> > ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> > d)} \
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> > ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> > '',d)} \
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
> > d.setVar("ADD_3G", "packagegroup-base-3g")
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
> > = "Cellular data support"
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
> > = "\
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
> > = "\
>
>
>
> So it's actually in the same file that we already opened. Here you can
> facepalm,
> but we didn't know that, so this would be the procedure anyways to track it
> down.
> Now, search for *packagegroup-base-3g* inside the
> *poky/meta/recipes-core/packagegroups/packagegroup-base.bb
> *
> and you see this line:
>
> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> > d)} \
>
>
> Therefore the *3g* in the *DISTRO_FEATURES* actually added *ofono*. That
> means that,
> we need to remove the *3g* string from our *DISTRO_FEATURES*.
>
> To do that, add this to your build/conf/local.conf file
>
> DISTRO_FEATURES_remove = " 3g"
>
>
> Now just to be sure, run this to clean *ofono* from cache
Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE
Hi, >From my experience, what CMAKE_BUILD_TYPE means varies between SW components. Thus I think the current approach of not setting it is correct. SW components must set their own defaults in either CMakeLists.txt or in the bitbake recipe. Also, building with debug info is separate from CMAKE_BUILD_TYPE. The default compile flags from yocto will include -g for debug symbols and this is provided to CMake compile flags too. Cheers, -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libstdc++fs on toolchain
On Thu, Jan 24, 2019 at 03:24:00PM +, João Gonçalves wrote: > Hello, > I'm trying to build a c++ cross toolchain to compile to imx6 (armv7). But I > need libstdc++fs library, which does not come with it. Until gcc 8.0 this > is an experimental library. > > I've tested with gcc 7.3 and with gcc 8.2 and and none have the libstdc++fs > library. > On my host machine the library is at > /usr/lib/gcc/x86_64-linux-gnu/7/libstdc++fs.a > > Does anyone know how to include this library on a yocto generated toolchain? At least on x86 targets, it's available from gcc-runtime recipe and libstdc++-staticdev binary package on sumo/yocto 2.5 and later. -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
