Re: [yocto] Using prelink in Thud and subsequent

curity_flags.inc. > > Ross > > On Fri, 4 Jan 2019 at 15:50, Matt Hoosier wrote: > > > > Hi all, > > > > With the following change, position-independent executables became the > default in Poky: > > > > commit 491082c56ce34f3fd644f8d4457c

[yocto] Using prelink in Thud and subsequent

Hi all, With the following change, position-independent executables became the default in Poky: commit 491082c56ce34f3fd644f8d4457ccd52af951087 Author: Khem Raj Date: Fri Jul 27 19:46:14 2018 -0700 poky.conf: Enable security flags+pie by defaultEnable security flags+pie by This has b

[yocto] [prelink-cross][PATCH] Support config dropfiles

.conf. Signed-off-by: Matt Hoosier --- doc/prelink.8 | 18 +- doc/prelink.tex | 2 +- src/gather.c| 26 ++ 3 files changed, 40 insertions(+), 6 deletions(-) diff --git a/doc/prelink.8 b/doc/prelink.8 index 215445e..9bdd247 100644 --- a/doc/prelink.8 +++

[yocto] [meta-mingw] Previous adventures in attempting a nativesdk-python ?

I've recently been wishing that it were possible to supply a working MinGW build of Python so that various utilities implemented in Python (e.g., nativesdk-glib-2.0-codegen) could be included in SDK's built with meta-mingw. There are some directions [1] that claim to provide sufficient patches to

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

Thanks for the reply. On Wed, Jul 25, 2018 at 4:58 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Wed, 2018-07-25 at 08:47 -0500, Matt Hoosier wrote: > > Quite a while ago I wrote the following message: > > On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

(Cross-posting to bitbake-devel.) Quite a while ago I wrote the following message: On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier wrote: > In order to support a use-case that embeds information about the Git > revision of Yocto itself that was used to make a build, I would like to run

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

On Wed, May 9, 2018 at 6:27 PM, Andre McCurdy wrote: > On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier > wrote: > > From: Matt Hoosier > > > > Although the submodules' histories have been fetched during the > > do_fetch() phase, the mechanics used to clone the w

[yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

From: Matt Hoosier Although the submodules' histories have been fetched during the do_fetch() phase, the mechanics used to clone the workdir copy of the repo haven't been transferring the actual .git/modules directory from the repo fetched into downloads/ during the fetch task. Fix

[yocto] Enforcing version constraints on dependencies at build-time

The RDEPENDS variable supports giving numeric version bounds. For example: RDEPENDS_${PN} = "foo (>= 1.3)" That works well for getting version dependencies respected at rootfs time. But DEPENDS (used at build-time) silently ignores any similar constraint arguments. For example: DEPENDS = "fo

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

On Wed, Jan 25, 2017 at 3:03 AM, André Draszik wrote: > On Tue, 2017-01-24 at 11:55 -0600, Matt Hoosier wrote: > > In order to support a use-case that embeds information about the Git > > revision of Yocto itself that was used to make a build, I would like to > > run >

[yocto] Ordering of anonymous Python functions and task signature calculations

In order to support a use-case that embeds information about the Git revision of Yocto itself that was used to make a build, I would like to run some arbitrary Python code and dump the results (Git SHA1's, tag names, etc) into a Bitbake variable. The idea is that the variable would get consumed in

[yocto] SRC_URI overrides and work-shared

In my private layer, I'd like to apply the occasional patch to GCC only for certain circumstances (e.g., a particular target architecture). I get some strange behavior with quilt seeming to get confused during do_patch(), though, which I imagine is due to the singular source directory in build/tmp/

Re: [yocto] Installing the SDKs made with meta-mingw

On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson wrote: > > > On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson > wrote: > >> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier >> wrote: >> >>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier >>>

[yocto] [meta-qt5] [meta-mingw] Any success using these two layers together?

Does anybody have experience using meta-qt5 and meta-ming together to produce a usable SDK including Qt development tools for use on a Windows host together? The stock recipes for producing the nativesdk flavors of certain Qt packages would seem to require some modification from vanilla meta-qt5 u

Re: [yocto] Installing the SDKs made with meta-mingw

On Thu, Mar 17, 2016 at 11:56 AM, Christopher Larson wrote: > > > On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier > wrote: > >> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson > > wrote: >> >>> >>> >>> On Thu, Mar 17, 2016 at 8:

[yocto] Installing the SDKs made with meta-mingw

Hi, I've successfully built a Canadian-cross SDK using the meta-mingw layer. Very nice! Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not encapsulated into the self-extracting tarball and the corresponding relocation l

Re: [yocto] Installing the SDKs made with meta-mingw

On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson wrote: > On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier > wrote: > >> I've successfully built a Canadian-cross SDK using the meta-mingw layer. >> Very nice! >> >> Because the layer lobotomizes the SDK_PACKA

Re: [yocto] Installing the SDKs made with meta-mingw

On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier wrote: > > > On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson > wrote: > >> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier >> wrote: >> >>> I've successfully built a Canadian-cross SDK using the m