Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Alexander Kanavin <alexander.kanavin@linux.intel.com>
To: "Bystricky, Juro" <juro.bystricky@intel.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Cc: "jurobystricky@hotmail.com" <jurobystricky@hotmail.com>
Subject: Re: [PATCH] glib-2.0/glib.inc: fix broken mingw build
Date: Sat, 14 Apr 2018 00:03:34 +0300	[thread overview]
Message-ID: <ac957064-a261-4de6-ff19-b751e12a65c0@linux.intel.com> (raw)
In-Reply-To: <6E51916E4A1F32428260031F4C7CD2B64C6A939E@ORSMSX112.amr.corp.intel.com>

On 04/13/2018 11:29 PM, Bystricky, Juro wrote:
> Yes, I do get warnings, but in both cases (skipping the renaming and also if renamed  with MLPREFIX):
> WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept hook 'update_gio_module_cache-nativesdk' failed, details in /data/master-master/poky/build-x86_64-mingw32-sdk-core-image-minimal/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk
> 
> So skipping the renaming will at least give me a correctly named executable in the package.

The correctly named executable is the renamed one, as it is then 
consistent with what is in every other nativesdk- package (Linux-hosted 
ones), so the intercept script can properly pick it up. It is not used 
anywhere else except there.

> Are you sure the postinst-intercepts can even work with Windows .exe executables?
> If I understand this correctly, you use a qemuwrapper attempting to run Windows executable, and I
> cannot imagine this would work. But maybe I am missing something here.

This is tangential to how the executable should be called. Yes, the 
qemuwrapper is allowed to fail, that why it's a warning and not a hard 
failure. When building target images, the fallback to this failure is 
deferring the script to first boot. For SDKs we currently do nothing, 
which means package installation isn't really completed. If SDKs aren't 
able to function properly because of this, we can implement a similar 
deferral of some kind to the environment where those binaries can be 
executed natively without emulation.

Alex


      reply	other threads:[~2018-04-13 21:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 22:28 [PATCH] glib-2.0/glib.inc: fix broken mingw build Juro Bystricky
2018-04-13  6:48 ` Alexander Kanavin
2018-04-13 14:43   ` Bystricky, Juro
2018-04-13 19:32     ` Alexander Kanavin
2018-04-13 20:29       ` Bystricky, Juro
2018-04-13 21:03         ` Alexander Kanavin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac957064-a261-4de6-ff19-b751e12a65c0@linux.intel.com \
    --to=alexander.kanavin@linux.intel.com \
    --cc=juro.bystricky@intel.com \
    --cc=jurobystricky@hotmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox