Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
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.
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.
BTW, I cannot remedy this in the meta-mingw layer via a .bbppend, as the code
that needs to
be modified is in do_install_append, so it is not possible (or not easy) to use
overrides.
From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, April 13, 2018 12:32 PM
To: Bystricky, Juro; openembedded-core@lists.openembedded.org
Cc: richard.pur...@linuxfoundation.org; jurobystri...@hotmail.com
Subject: Re: [PATCH] glib-2.0/glib.inc: fix broken mingw build
On 04/13/2018 05:43 PM, Bystricky, Juro wrote:
>> I think the better approach is to accommodate the exe suffix when doing
>> the move:
>
>> mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
>> ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}
>
> This was actually the first thing I tried. However, I ended up with
> "nativesdk-gio-querymodules.exe"
> in the mingw tarrball (in my case
> poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
> I am not sure what you expect postinst to do for Windows toolchains/SDKs, but
> I would expect
> "gio-querymodules.exe", as it used to be until recently.
"nativesdk-gio-querymodules.exe" is totally fine. This utility is used
in only one place:
poky/scripts/postinst-intercepts/update_gio_module_cache, to generate
the cache file of gio modules whenever the gio modules are installed or
removed.
That script is called by postinst_intercept mechanism, which is
triggered via meta/classes/gio-module-cache.bbclass every time a package
that inherits that class is installed.
I am fairly sure that with the patch you sent it is not going to work
for the nativesdk mingw case, as the script does prepend the MLPREFIX to
the utility name (to call the correct version among many when multilib
is in use). We would probably need to append the .exe suffix in there as
well though.
Please do try populate_sdk with nativesdk-glib-2.0 included into it and
watch for any warnings about failed postinst_intercepts.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
On 04/13/2018 05:43 PM, Bystricky, Juro wrote:
I think the better approach is to accommodate the exe suffix when doing
the move:
mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}
This was actually the first thing I tried. However, I ended up with
"nativesdk-gio-querymodules.exe"
in the mingw tarrball (in my case
poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I
would expect
"gio-querymodules.exe", as it used to be until recently.
"nativesdk-gio-querymodules.exe" is totally fine. This utility is used
in only one place:
poky/scripts/postinst-intercepts/update_gio_module_cache, to generate
the cache file of gio modules whenever the gio modules are installed or
removed.
That script is called by postinst_intercept mechanism, which is
triggered via meta/classes/gio-module-cache.bbclass every time a package
that inherits that class is installed.
I am fairly sure that with the patch you sent it is not going to work
for the nativesdk mingw case, as the script does prepend the MLPREFIX to
the utility name (to call the correct version among many when multilib
is in use). We would probably need to append the .exe suffix in there as
well though.
Please do try populate_sdk with nativesdk-glib-2.0 included into it and
watch for any warnings about failed postinst_intercepts.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
> I think the better approach is to accommodate the exe suffix when doing
> the move:
> mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
> ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}
This was actually the first thing I tried. However, I ended up with
"nativesdk-gio-querymodules.exe"
in the mingw tarrball (in my case
poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I
would expect
"gio-querymodules.exe", as it used to be until recently.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
On 04/13/2018 01:28 AM, Juro Bystricky wrote:
mingw build was broken by the commit:
"glib-2.0/glib.inc: apply MLPREFIX renaming to all package classes"
When building for mingw, we encounter build errors such as:
mv: cannot stat '/<...>/usr/libexec/gio-querymodules': No such
file or directory
The file that exists is actually "gio-querymodules.exe", but still there is no
good reason to rename it to "nativesdk-gio-querymodules.exe".
So for mingw we simply avoid renaming of the executable, by skippng the line:
mv -v ${D}${libexecdir}/gio-querymodules
${D}${libexecdir}/${MLPREFIX}gio-querymodules
[YOCTO #12679]
The reason for the renaming is that postinst_intercept logic will try to
execute the binary with the mlprefix, when running populate_sdk. I think
this is not gonna work with your patch, and the bug does not mention
that you tried it.
I think the better approach is to accommodate the exe suffix when doing
the move:
mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build
mingw build was broken by the commit:
"glib-2.0/glib.inc: apply MLPREFIX renaming to all package classes"
When building for mingw, we encounter build errors such as:
mv: cannot stat '/<...>/usr/libexec/gio-querymodules': No such file
or directory
The file that exists is actually "gio-querymodules.exe", but still there is no
good reason to rename it to "nativesdk-gio-querymodules.exe".
So for mingw we simply avoid renaming of the executable, by skippng the line:
mv -v ${D}${libexecdir}/gio-querymodules
${D}${libexecdir}/${MLPREFIX}gio-querymodules
[YOCTO #12679]
Signed-off-by: Juro Bystricky
---
meta/recipes-core/glib-2.0/glib.inc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index b7c32e6..92ac19e 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -91,6 +91,9 @@ USE_NLS_class-target = "yes"
USE_NLS_class-nativesdk = "yes"
CACHED_CONFIGUREVARS_append_class-native = " ac_cv_path_MSGFMT=/bin/false"
+EXEEXT = ""
+EXEEXT_mingw32 = ".exe"
+
do_install_append () {
if [ -f ${D}${bindir}/gtester-report ]; then
sed ${D}${bindir}/gtester-report -i -e '1s|^#!.*|#!/usr/bin/env
python3|'
@@ -106,7 +109,7 @@ do_install_append () {
fi
# Make sure gio-querymodules is unique among multilibs
-if test "x${MLPREFIX}" != "x"; then
+if test "x${MLPREFIX}" != "x" && test "${EXEEXT}" != ".exe"; then
mv ${D}${libexecdir}/gio-querymodules
${D}${libexecdir}/${MLPREFIX}gio-querymodules
fi
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
