* [PATCH 2/7] python3: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
@ 2018-03-12 9:12 ` Zhang Xiao
2018-03-12 9:12 ` [PATCH 3/7] vala: " Zhang Xiao
` (5 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:12 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Config file python3.5m-config conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
meta/recipes-devtools/python/python3_3.5.4.bb | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3_3.5.4.bb b/meta/recipes-devtools/python/python3_3.5.4.bb
index a94d0096f1..7544e3318c 100644
--- a/meta/recipes-devtools/python/python3_3.5.4.bb
+++ b/meta/recipes-devtools/python/python3_3.5.4.bb
@@ -48,7 +48,13 @@ UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P<pver>\d+(\.\d+)+).tar"
S = "${WORKDIR}/Python-${PV}"
-inherit autotools multilib_header python3native pkgconfig
+inherit autotools multilib_header python3native pkgconfig update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-core = "python3.5m-config"
+ALTERNATIVE_LINK_NAME[python3.5m-config] = "${bindir}/python3.5m-config"
+ALTERNATIVE_TARGET[python3.5m-config] = "${bindir}/python3.5m-config-${MULTILIB_SUFFIX}"
CONFIGUREOPTS += " --with-system-ffi "
@@ -204,6 +210,8 @@ py_package_preprocess () {
${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} \
-c "from py_compile import compile; compile('./${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py', optimize=2)"
cd -
+
+ mv ${PKGD}/${bindir}/python3.5m-config ${PKGD}/${bindir}/python3.5m-config-${MULTILIB_SUFFIX}
}
# manual dependency additions
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 3/7] vala: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
2018-03-12 9:12 ` [PATCH 2/7] python3: " Zhang Xiao
@ 2018-03-12 9:12 ` Zhang Xiao
2018-03-12 9:13 ` [PATCH 4/7] gobject-introspection: " Zhang Xiao
` (4 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:12 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Config file vala-gen-introspect-${SHRT_VER} conflicts between 32 and
64 bit packages. Use update-alternatives to add base_libdir as suffix
to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
meta/recipes-devtools/vala/vala.inc | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/vala/vala.inc b/meta/recipes-devtools/vala/vala.inc
index b22faad780..5c958cdbf0 100644
--- a/meta/recipes-devtools/vala/vala.inc
+++ b/meta/recipes-devtools/vala/vala.inc
@@ -19,7 +19,20 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
SHRT_VER = "${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
SRC_URI = "http://ftp.gnome.org/pub/GNOME/sources/${BPN}/${SHRT_VER}/${BP}.tar.xz"
-inherit autotools pkgconfig upstream-version-is-even
+inherit autotools pkgconfig upstream-version-is-even update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+ALTERNATIVE_${PN} = "vala-gen-introspect"
+ALTERNATIVE_LINK_NAME[vala-gen-introspect] = "${bindir}/vala-gen-introspect-${SHRT_VER}"
+ALTERNATIVE_TARGET[vala-gen-introspect] = "${bindir}/vala-gen-introspect-${SHRT_VER}-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternative_rename"
+
+alternative_rename() {
+ mv ${PKGD}${bindir}/vala-gen-introspect-${SHRT_VER} \
+ ${PKGD}${bindir}/vala-gen-introspect-${SHRT_VER}-${MULTILIB_SUFFIX}
+}
+
FILES_${PN} += "${datadir}/${BPN}-${SHRT_VER}/vapi ${libdir}/${BPN}-${SHRT_VER}/"
FILES_${PN}-doc += "${datadir}/devhelp"
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4/7] gobject-introspection: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
2018-03-12 9:12 ` [PATCH 2/7] python3: " Zhang Xiao
2018-03-12 9:12 ` [PATCH 3/7] vala: " Zhang Xiao
@ 2018-03-12 9:13 ` Zhang Xiao
2018-03-12 9:13 ` [PATCH 5/7] cairo: " Zhang Xiao
` (3 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:13 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Script files conflict between 32 and 64 bit packages:
${bindir}/g-ir-annotation-tool
${bindir}/g-ir-compiler-wrapper
${bindir}/g-ir-scanner
${bindir}/g-ir-scanner-lddwrapper
${bindir}/g-ir-scanner-qemuwrapper
${bindir}/g-ir-scanner-wrapper
${datadir}/gir-1.0/GLib-2.0.gir
Use update-alternatives to add base_libdir as suffix to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
.../gobject-introspection_1.54.1.bb | 34 +++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
index 85c8001dea..d9d5825a78 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
@@ -19,9 +19,41 @@ SRC_URI = "${GNOME_MIRROR}/${BPN}/1.54/${BPN}-${PV}.tar.xz \
SRC_URI[md5sum] = "126c29e4d54adbed2ed4e2b04483de41"
SRC_URI[sha256sum] = "b88ded5e5f064ab58a93aadecd6d58db2ec9d970648534c63807d4f9a7bb877e"
-inherit autotools pkgconfig gtk-doc python3native qemu gobject-introspection-data upstream-version-is-even
+inherit autotools pkgconfig gtk-doc python3native qemu gobject-introspection-data upstream-version-is-even update-alternatives
BBCLASSEXTEND = "native"
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+ALTERNATIVE_${PN} = "annotation-tool compiler-wrapper scanner scanner-lddwrapper scanner-qemuwrapper scanner-wrapper"
+ALTERNATIVE_${PN}-dev = "GLib-2.0.gir"
+ALTERNATIVE_LINK_NAME[annotation-tool] = "${bindir}/g-ir-annotation-tool"
+ALTERNATIVE_TARGET[annotation-tool] = "${bindir}/g-ir-annotation-tool-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[compiler-wrapper] = "${bindir}/g-ir-compiler-wrapper"
+ALTERNATIVE_TARGET[compiler-wrapper] = "${bindir}/g-ir-compiler-wrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner] = "${bindir}/g-ir-scanner"
+ALTERNATIVE_TARGET[scanner] = "${bindir}/g-ir-scanner-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-lddwrapper] = "${bindir}/g-ir-scanner-lddwrapper"
+ALTERNATIVE_TARGET[scanner-lddwrapper] = "${bindir}/g-ir-scanner-lddwrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-qemuwrapper] = "${bindir}/g-ir-scanner-qemuwrapper"
+ALTERNATIVE_TARGET[scanner-qemuwrapper] = "${bindir}/g-ir-scanner-qemuwrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-wrapper] = "${bindir}/g-ir-scanner-wrapper"
+ALTERNATIVE_TARGET[scanner-wrapper] = "${bindir}/g-ir-scanner-wrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[GLib-2.0.gir] = "${datadir}/gir-1.0/GLib-2.0.gir"
+ALTERNATIVE_TARGET[GLib-2.0.gir] = "${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}"
+
+FILES_${PN}-dev += "${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "gobject_alternative_rename"
+
+gobject_alternative_rename() {
+ mv ${PKGD}${bindir}/g-ir-annotation-tool ${PKGD}${bindir}/g-ir-annotation-tool-${MULTILIB_SUFFIX}
+ mv ${PKGD}${bindir}/g-ir-compiler-wrapper ${PKGD}${bindir}/g-ir-compiler-wrapper-${MULTILIB_SUFFIX}
+ mv ${PKGD}${bindir}/g-ir-scanner ${PKGD}${bindir}/g-ir-scanner-${MULTILIB_SUFFIX}
+ mv ${PKGD}${bindir}/g-ir-scanner-lddwrapper ${PKGD}${bindir}/g-ir-scanner-lddwrapper-${MULTILIB_SUFFIX}
+ mv ${PKGD}${bindir}/g-ir-scanner-qemuwrapper ${PKGD}${bindir}/g-ir-scanner-qemuwrapper-${MULTILIB_SUFFIX}
+ mv ${PKGD}${bindir}/g-ir-scanner-wrapper ${PKGD}${bindir}/g-ir-scanner-wrapper-${MULTILIB_SUFFIX}
+ mv ${PKGD}${datadir}/gir-1.0/GLib-2.0.gir ${PKGD}${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}
+}
+
# needed for writing out the qemu wrapper script
export STAGING_DIR_HOST
export B
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 5/7] cairo: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
` (2 preceding siblings ...)
2018-03-12 9:13 ` [PATCH 4/7] gobject-introspection: " Zhang Xiao
@ 2018-03-12 9:13 ` Zhang Xiao
2018-03-16 15:56 ` Burton, Ross
2018-03-12 9:13 ` [PATCH 6/7] xtrans: " Zhang Xiao
` (2 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:13 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Script file cairo-trace conflict between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
meta/recipes-graphics/cairo/cairo_1.14.12.bb | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/cairo/cairo_1.14.12.bb b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
index 075ca1ed34..1f2d68c0de 100644
--- a/meta/recipes-graphics/cairo/cairo_1.14.12.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
@@ -10,6 +10,20 @@ SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.xz \
SRC_URI[md5sum] = "9f0db9dbfca0966be8acd682e636d165"
SRC_URI[sha256sum] = "8c90f00c500b2299c0a323dd9beead2a00353752b2092ead558139bd67f7bf16"
+inherit update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-perf-utils="cairo-trace"
+ALTERNATIVE_LINK_NAME[cairo-trace] = "${bindir}/cairo-trace"
+ALTERNATIVE_TARGET[cairo-trace] = "${bindir}/cairo-trace-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternatives_rename"
+
+alternatives_rename() {
+ mv ${PKGD}${bindir}/cairo-trace ${PKGD}${bindir}/cairo-trace-${MULTILIB_SUFFIX}
+}
+
PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
SUMMARY_${PN} = "The Cairo 2D vector graphics library"
@@ -35,7 +49,7 @@ FILES_${PN} = "${libdir}/libcairo.so.*"
FILES_${PN}-dev += "${libdir}/cairo/*.so"
FILES_${PN}-gobject = "${libdir}/libcairo-gobject.so.*"
FILES_${PN}-script-interpreter = "${libdir}/libcairo-script-interpreter.so.*"
-FILES_${PN}-perf-utils = "${bindir}/cairo-trace ${libdir}/cairo/*.la ${libdir}/cairo/libcairo-trace.so.*"
+FILES_${PN}-perf-utils = "${bindir}/cairo-trace* ${libdir}/cairo/*.la ${libdir}/cairo/libcairo-trace.so.*"
do_install_append () {
rm -rf ${D}${bindir}/cairo-sphinx
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 5/7] cairo: fix file conflict when multilib enabled
2018-03-12 9:13 ` [PATCH 5/7] cairo: " Zhang Xiao
@ 2018-03-16 15:56 ` Burton, Ross
0 siblings, 0 replies; 17+ messages in thread
From: Burton, Ross @ 2018-03-16 15:56 UTC (permalink / raw)
To: Zhang Xiao; +Cc: OE-core
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
Or, don't install a *binary* package in two multilib architectures at once.
Ross
On 12 March 2018 at 09:13, Zhang Xiao <xiao.zhang@windriver.com> wrote:
> Script file cairo-trace conflict between 32 and 64 bit packages.
> Use update-alternatives to add base_libdir as suffix to avoid it.
>
> Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
> ---
> meta/recipes-graphics/cairo/cairo_1.14.12.bb | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/cairo/cairo_1.14.12.bb
> b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
> index 075ca1ed34..1f2d68c0de 100644
> --- a/meta/recipes-graphics/cairo/cairo_1.14.12.bb
> +++ b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
> @@ -10,6 +10,20 @@ SRC_URI = "http://cairographics.org/
> releases/cairo-${PV}.tar.xz \
> SRC_URI[md5sum] = "9f0db9dbfca0966be8acd682e636d165"
> SRC_URI[sha256sum] = "8c90f00c500b2299c0a323dd9beead
> 2a00353752b2092ead558139bd67f7bf16"
>
> +inherit update-alternatives
> +
> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
> +
> +ALTERNATIVE_${PN}-perf-utils="cairo-trace"
> +ALTERNATIVE_LINK_NAME[cairo-trace] = "${bindir}/cairo-trace"
> +ALTERNATIVE_TARGET[cairo-trace] = "${bindir}/cairo-trace-${
> MULTILIB_SUFFIX}"
> +
> +PACKAGE_PREPROCESS_FUNCS += "alternatives_rename"
> +
> +alternatives_rename() {
> + mv ${PKGD}${bindir}/cairo-trace ${PKGD}${bindir}/cairo-trace-$
> {MULTILIB_SUFFIX}
> +}
> +
> PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
>
> SUMMARY_${PN} = "The Cairo 2D vector graphics library"
> @@ -35,7 +49,7 @@ FILES_${PN} = "${libdir}/libcairo.so.*"
> FILES_${PN}-dev += "${libdir}/cairo/*.so"
> FILES_${PN}-gobject = "${libdir}/libcairo-gobject.so.*"
> FILES_${PN}-script-interpreter = "${libdir}/libcairo-script-
> interpreter.so.*"
> -FILES_${PN}-perf-utils = "${bindir}/cairo-trace ${libdir}/cairo/*.la
> ${libdir}/cairo/libcairo-trace.so.*"
> +FILES_${PN}-perf-utils = "${bindir}/cairo-trace* ${libdir}/cairo/*.la
> ${libdir}/cairo/libcairo-trace.so.*"
>
> do_install_append () {
> rm -rf ${D}${bindir}/cairo-sphinx
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 3866 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 6/7] xtrans: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
` (3 preceding siblings ...)
2018-03-12 9:13 ` [PATCH 5/7] cairo: " Zhang Xiao
@ 2018-03-12 9:13 ` Zhang Xiao
2018-03-16 15:55 ` Burton, Ross
2018-03-12 9:13 ` [PATCH 7/7] icu: " Zhang Xiao
2018-03-12 10:13 ` [PATCH 1/7] eudev: " Alexander Kanavin
6 siblings, 1 reply; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:13 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Script file xtrans.pc conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
index d5b7f1a2c6..ef64f1fcfc 100644
--- a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
+++ b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
@@ -16,7 +16,20 @@ PE = "1"
RDEPENDS_${PN}-dev = ""
-inherit gettext
+inherit gettext update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+FILES_${PN}-dev += "${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}"
+ALTERNATIVE_${PN}-dev = "xtrans.pc"
+ALTERNATIVE_LINK_NAME[xtrans.pc] = "${datadir}/pkgconfig/xtrans.pc"
+ALTERNATIVE_TARGET[xtrans.pc] = "${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "xtrans_alternative_rename"
+
+xtrans_alternative_rename() {
+ mv ${PKGD}${datadir}/pkgconfig/xtrans.pc ${PKGD}${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}
+}
BBCLASSEXTEND = "native nativesdk"
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 6/7] xtrans: fix file conflict when multilib enabled
2018-03-12 9:13 ` [PATCH 6/7] xtrans: " Zhang Xiao
@ 2018-03-16 15:55 ` Burton, Ross
0 siblings, 0 replies; 17+ messages in thread
From: Burton, Ross @ 2018-03-16 15:55 UTC (permalink / raw)
To: Zhang Xiao; +Cc: OE-core
[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]
Is this because they use libdir? Surely a better solution would be to move
the .pc into $libdir/pkgconfig instead of $datadir/pkgconfig?
Ross
On 12 March 2018 at 09:13, Zhang Xiao <xiao.zhang@windriver.com> wrote:
> Script file xtrans.pc conflicts between 32 and 64 bit packages.
> Use update-alternatives to add base_libdir as suffix to avoid it.
>
> Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
> ---
> meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
> b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
> index d5b7f1a2c6..ef64f1fcfc 100644
> --- a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
> +++ b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
> @@ -16,7 +16,20 @@ PE = "1"
>
> RDEPENDS_${PN}-dev = ""
>
> -inherit gettext
> +inherit gettext update-alternatives
> +
> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
> +
> +FILES_${PN}-dev += "${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}"
> +ALTERNATIVE_${PN}-dev = "xtrans.pc"
> +ALTERNATIVE_LINK_NAME[xtrans.pc] = "${datadir}/pkgconfig/xtrans.pc"
> +ALTERNATIVE_TARGET[xtrans.pc] = "${datadir}/pkgconfig/xtrans.
> pc-${MULTILIB_SUFFIX}"
> +
> +PACKAGE_PREPROCESS_FUNCS += "xtrans_alternative_rename"
> +
> +xtrans_alternative_rename() {
> + mv ${PKGD}${datadir}/pkgconfig/xtrans.pc
> ${PKGD}${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}
> +}
>
> BBCLASSEXTEND = "native nativesdk"
>
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 3020 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 7/7] icu: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
` (4 preceding siblings ...)
2018-03-12 9:13 ` [PATCH 6/7] xtrans: " Zhang Xiao
@ 2018-03-12 9:13 ` Zhang Xiao
2018-03-12 10:13 ` [PATCH 1/7] eudev: " Alexander Kanavin
6 siblings, 0 replies; 17+ messages in thread
From: Zhang Xiao @ 2018-03-12 9:13 UTC (permalink / raw)
To: openembedded-core, mark.hatle
Script icu-config conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
---
meta/recipes-support/icu/icu.inc | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/icu/icu.inc b/meta/recipes-support/icu/icu.inc
index 983118cd61..5dc4e1dbb9 100644
--- a/meta/recipes-support/icu/icu.inc
+++ b/meta/recipes-support/icu/icu.inc
@@ -19,7 +19,19 @@ BINCONFIG = "${bindir}/icu-config"
ICU_MAJOR_VER = "${@d.getVar('PV').split('.')[0]}"
-inherit autotools pkgconfig binconfig
+inherit autotools pkgconfig binconfig update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-dev = "icu-config"
+ALTERNATIVE_LINK_NAME[icu-config] = "${bindir}/icu-config"
+ALTERNATIVE_TARGET[icu-config] = "${bindir}/icu-config-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternatives_rename"
+
+alternatives_rename() {
+ mv ${PKGD}/${bindir}/icu-config ${PKGD}/${bindir}/icu-config-${MULTILIB_SUFFIX}
+}
# ICU needs the native build directory as an argument to its --with-cross-build option when
# cross-compiling. Taken the situation that different builds may share a common sstate-cache
@@ -76,7 +88,7 @@ do_install_append_class-target() {
PACKAGES =+ "libicudata libicuuc libicui18n libicutu libicuio"
-FILES_${PN}-dev += "${libdir}/${BPN}/"
+FILES_${PN}-dev += "${libdir}/${BPN}/ ${bindir}/icu-config-${MULTILIB_SUFFIX}"
FILES_libicudata = "${libdir}/libicudata.so.*"
FILES_libicuuc = "${libdir}/libicuuc.so.*"
--
2.11.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-12 9:12 [PATCH 1/7] eudev: fix file conflict when multilib enabled Zhang Xiao
` (5 preceding siblings ...)
2018-03-12 9:13 ` [PATCH 7/7] icu: " Zhang Xiao
@ 2018-03-12 10:13 ` Alexander Kanavin
2018-03-12 18:38 ` Mark Hatle
6 siblings, 1 reply; 17+ messages in thread
From: Alexander Kanavin @ 2018-03-12 10:13 UTC (permalink / raw)
To: Zhang Xiao, openembedded-core, mark.hatle
On 03/12/2018 11:12 AM, Zhang Xiao wrote:
> Config file udev.pc conflicts between 32 and 64 bit packages.
> Use update-alternatives to add base_libdir as suffix to avoid it.
> -inherit autotools update-rc.d qemu pkgconfig distro_features_check
> +inherit autotools update-rc.d qemu pkgconfig distro_features_check update-alternatives
> +
> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
> +
> +ALTERNATIVE_${PN}-dev = "udev.pc"
> +ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
> +ALTERNATIVE_TARGET[udev.pc] = "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
> +
> +PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
> +
> +eudev_alternative_rename() {
> + # rename udev.pc
> + mv ${PKGD}${datadir}/pkgconfig/udev.pc ${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
> +}
I'm afraid, I have to say no to the entire patchset. It's abusing
update-alternatives to do what it was never meant for, and effectively
renders one of the -dev packages broken, just so that package manager
can satisfy dependencies.
Let's first take a look at why dnf wants to install two different -dev
packages in the first place, and why these seven recipes need to be
fixed in particular. My understanding is multilib feature should be used
only for libraries, and not for supporting development files.
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-12 10:13 ` [PATCH 1/7] eudev: " Alexander Kanavin
@ 2018-03-12 18:38 ` Mark Hatle
2018-03-12 18:55 ` Alexander Kanavin
0 siblings, 1 reply; 17+ messages in thread
From: Mark Hatle @ 2018-03-12 18:38 UTC (permalink / raw)
To: Alexander Kanavin, Zhang Xiao, openembedded-core
On 3/12/18 3:13 AM, Alexander Kanavin wrote:
> On 03/12/2018 11:12 AM, Zhang Xiao wrote:
>> Config file udev.pc conflicts between 32 and 64 bit packages.
>> Use update-alternatives to add base_libdir as suffix to avoid it.
>> -inherit autotools update-rc.d qemu pkgconfig distro_features_check
>> +inherit autotools update-rc.d qemu pkgconfig distro_features_check update-alternatives
>> +
>> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
>> +
>> +ALTERNATIVE_${PN}-dev = "udev.pc"
>> +ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
>> +ALTERNATIVE_TARGET[udev.pc] = "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
>> +
>> +PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
>> +
>> +eudev_alternative_rename() {
>> + # rename udev.pc
>> + mv ${PKGD}${datadir}/pkgconfig/udev.pc ${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
>> +}
>
> I'm afraid, I have to say no to the entire patchset. It's abusing
> update-alternatives to do what it was never meant for, and effectively
> renders one of the -dev packages broken, just so that package manager
> can satisfy dependencies.
>
> Let's first take a look at why dnf wants to install two different -dev
> packages in the first place, and why these seven recipes need to be
> fixed in particular. My understanding is multilib feature should be used
> only for libraries, and not for supporting development files.
In this case, because the user specifically asked for BOTH 32-bit and 64-bit
development components to be installed onto the target for their application
development. (This isn't a theoretical problem, but a specific problem from one
of our customers.)
I had a chance to talk to RP a bit about this today at ELC. We agree we need a
generic mechanism to handle these types of problems.
For a '.pc' file, there really should be no reason (under normal circumstances)
for them to conflict. Since if they are are specific they don't belong in the
datadir, but belong in the libdir.
For non-.pc files, if they are 'pkgconfig like', they should be converted to
package config (for the most part this seems to have happened, with a few things
'missed'.)
The remainder then are things that can't be converted for some reason. So the
'config', or helper or whatever files really need to 'match' the installed binary.
There is no way to predict ahead of time which binary is going to be installed
-- so we really need some type of automated processing that can be used to say:
1) This is a known multilib issue.
2) This file is related to this other file, and should be installed to match.
Under the hood if it uses update-alternatives or anything else doesn't matter --
but in the recipe it should not explicitly require the rename, the ALTERNATIVE
and related declarations etc...
Perhaps something like:
MULTILIB_CONFLICT = "${bindir}/python3.5m-config:${bindir}/python3.5m"
The under the hood it can rename the 'python3.5m-config' to a nonconflicting
name (based on the base_libdir, since we know that will be unique)... and then
invoke a post-install script that will define an appropriate priority to ensure
that python3.5m-config will match the final 'python3.5m' version. (Possibly
using update-alternatives to manage this.)
--Mark
> Alex
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-12 18:38 ` Mark Hatle
@ 2018-03-12 18:55 ` Alexander Kanavin
2018-03-12 19:48 ` Mark Hatle
0 siblings, 1 reply; 17+ messages in thread
From: Alexander Kanavin @ 2018-03-12 18:55 UTC (permalink / raw)
To: Mark Hatle, Zhang Xiao, openembedded-core
On 03/12/2018 08:38 PM, Mark Hatle wrote:
> In this case, because the user specifically asked for BOTH 32-bit and 64-bit
> development components to be installed onto the target for their application
> development. (This isn't a theoretical problem, but a specific problem from one
> of our customers.)
Fair enough, but you should explain to the customer that Unix-type
systems are not designed for this. There are hardcoded assumptions
everywhere, that for each component there's only one set of header
files, one .pc file, and one -config-style helper binary. Desktop
distributions mutually exclude multilib -dev packages for this reason.
> The under the hood it can rename the 'python3.5m-config' to a nonconflicting
> name (based on the base_libdir, since we know that will be unique)... and then
> invoke a post-install script that will define an appropriate priority to ensure
> that python3.5m-config will match the final 'python3.5m' version. (Possibly
> using update-alternatives to manage this.)
Here's something I don't get. When the user starts actual development,
and calls python3.5-config to fetch configuration values, how do we
ensure that the 'right' python3.5m-config is called, from the two that
are installed? Same question for pkgconfig - how do we make sure it
would look in the 'right' library directory of the two that are available?
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-12 18:55 ` Alexander Kanavin
@ 2018-03-12 19:48 ` Mark Hatle
2018-03-13 10:19 ` Alexander Kanavin
0 siblings, 1 reply; 17+ messages in thread
From: Mark Hatle @ 2018-03-12 19:48 UTC (permalink / raw)
To: Alexander Kanavin, Zhang Xiao, openembedded-core
On 3/12/18 11:55 AM, Alexander Kanavin wrote:
> On 03/12/2018 08:38 PM, Mark Hatle wrote:
>> In this case, because the user specifically asked for BOTH 32-bit and 64-bit
>> development components to be installed onto the target for their application
>> development. (This isn't a theoretical problem, but a specific problem from one
>> of our customers.)
>
> Fair enough, but you should explain to the customer that Unix-type
> systems are not designed for this. There are hardcoded assumptions
> everywhere, that for each component there's only one set of header
> files, one .pc file, and one -config-style helper binary. Desktop
> distributions mutually exclude multilib -dev packages for this reason.
The desktop distribution I used (CentOS and Fedora) support this type of
multilib-dev. I have to use the header file stuff all the time. I don't know
how they handle the -config case.
But for the .pc files, they are typically installing in the libdir (not the
datadir) for anything that is arch specific. So that resolves the multilib
issue for that piece.
>> The under the hood it can rename the 'python3.5m-config' to a nonconflicting
>> name (based on the base_libdir, since we know that will be unique)... and then
>> invoke a post-install script that will define an appropriate priority to ensure
>> that python3.5m-config will match the final 'python3.5m' version. (Possibly
>> using update-alternatives to manage this.)
>
> Here's something I don't get. When the user starts actual development,
> and calls python3.5-config to fetch configuration values, how do we
> ensure that the 'right' python3.5m-config is called, from the two that
> are installed? Same question for pkgconfig - how do we make sure it
> would look in the 'right' library directory of the two that are available?
For the pkgconfig side, pkgconfig (used to) check gcc for the libdir. I say
used to cause, I don't know if this was implemented in OE or not. I don't
remember. At one time, I believe this was done using "PKG_CONFIG_LIBDIR" and
re-execing the program... but it's been a long time since I looked or cared
specifically. Most '.pc' files I know of are identical for all multilibs..
having differences is really strange, and makes me really wonder if there are
other issues with the package producing them.
For the python3.5m-config stuff, (assuming we create a general purpose system to
resolve this). It should be able to query the executable that was installed and
figure out which base_libdir it is associated with, and then use that
information to switch to the correct '-config'. If the user knows they want a
specific libdir version, then that would be up to the specific user to invoke.
This way the user can run a version of the default with reasonable expectations
the default will match their running system -- or manually specific the file and
type they want to execute and get the exact version they care about.
I think my objective is, primarily, that the 'default' behavior of the system
needs to be reasonable. So for any user who does not declare a specific
'version to be used', the 'right thing happens automatically'. Where the right
thing would be:
*) Use a common configuration that works everywhere.
*) Determine [automatically] the configuration that matches the system.
*) Stop and tell the user that it does not know the right solution. (Error)
Then an advanced user to select a specific version of the 'alternatives'. The
key with all of this is that it needs to be 'reasonable' for both the recipe
maintainer and the end user. Having to manually rename things, use the existing
update-alternatives, etc really isn't a good idea -- even if it solves (some of)
the user issues.
--Mark
> Alex
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-12 19:48 ` Mark Hatle
@ 2018-03-13 10:19 ` Alexander Kanavin
2018-03-26 15:28 ` Mark Hatle
0 siblings, 1 reply; 17+ messages in thread
From: Alexander Kanavin @ 2018-03-13 10:19 UTC (permalink / raw)
To: Mark Hatle, Zhang Xiao, openembedded-core
On 03/12/2018 09:48 PM, Mark Hatle wrote:
> Then an advanced user to select a specific version of the 'alternatives'. The
> key with all of this is that it needs to be 'reasonable' for both the recipe
> maintainer and the end user. Having to manually rename things, use the existing
> update-alternatives, etc really isn't a good idea -- even if it solves (some of)
> the user issues.
But what is the specific need for having both 32 and 64 bit development
packages *installed at the same time*? You do need to explain this,
because any solution will add complexity and headaches for oe-core
maintainers, and multilib is already far too complex and tricky.
If the customer is fine with switching between the two sets, then this
can be trivially solved using existing tools:
1. Deinstall 32 bit dev packages on device.
2. Install matching 64 bit dev packages on device
... or vice versa. Just wrap it in a script.
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-13 10:19 ` Alexander Kanavin
@ 2018-03-26 15:28 ` Mark Hatle
2018-03-27 10:37 ` Alexander Kanavin
0 siblings, 1 reply; 17+ messages in thread
From: Mark Hatle @ 2018-03-26 15:28 UTC (permalink / raw)
To: Alexander Kanavin, Zhang Xiao, openembedded-core
On 3/13/18 5:19 AM, Alexander Kanavin wrote:
> On 03/12/2018 09:48 PM, Mark Hatle wrote:
>> Then an advanced user to select a specific version of the 'alternatives'. The
>> key with all of this is that it needs to be 'reasonable' for both the recipe
>> maintainer and the end user. Having to manually rename things, use the existing
>> update-alternatives, etc really isn't a good idea -- even if it solves (some of)
>> the user issues.
Back online after a business trip.
> But what is the specific need for having both 32 and 64 bit development
> packages *installed at the same time*? You do need to explain this,
> because any solution will add complexity and headaches for oe-core
> maintainers, and multilib is already far too complex and tricky.
Two user-cases.
The primary one is SDK generation. Right now creating a multilib SDK is causing
tons of failures for both headers and executables. The user is trying to build
ONE SDK that can build either 32-bit or 64-bit applications and they are getting
numerous failures during SDK creation. We've offered the workaround of two
SDKs, but needless to say that is far from ideal.
The secondary use-case is on-target generation. We're not talking about tiny
embedded systems here. We're talking about targets that have 192 or more cores
that are used for both executing code, as well as creating customized code
alternatives. (Think high-end routers, industrial control systems, etc.) In
this case, the biggest issue has been python. The user has a library, which for
some reason is available in either 32-bit or 64-bit mode (and ONLY that mode).
They don't have the source for that.. so they need to create a program that runs
on 32-bit python -- or 64-bit python to use the special library for the
processing that they are doing. This is unfortunately still very common.
The answer of 'just uninstall' one or the other doesn't solve that problem, as
they are both needed to create a functioning system.
A related case, it's really the same just different symptoms, is that we have
customers who are still needing to run -16-bit- IA code. Yes, you can run
16-bit IA code on Linux -- the key is that it runs in a 32-bit context. So now
you are forced to run both a 32-bit and 64-bit user space. 32-bit for legacy
(16-bit) code, and 64-bit for any new code. The immediate question is, well
then why are you shipping 'development' components for 32-bit, the customer
isn't in this case.. but once they enable 'dev-pkgs' in the image gen code, both
32-bit AND 64-bit get dev-pkgs and their system falls apart.
In this version of the case, you can't "just uninstall", but you instead now
have to convince the system to only install 64-bit dev components, but not
32-bit.. And there is no 'easy' way to do that in the current infrastructure.
> If the customer is fine with switching between the two sets, then this
> can be trivially solved using existing tools:
>
> 1. Deinstall 32 bit dev packages on device.
> 2. Install matching 64 bit dev packages on device
>
> ... or vice versa. Just wrap it in a script.
Switching really is not an option.
Update-alternatives work, but it's too complicated and not exactly 'automatic'.
We don't want to have recipe maintainers try to understand the complexities of
update-alternative priorities and such. There is also no guaranty that the
selected script and ELF executable [or matching library]) is of the matching
type. So while it's A solution -- it's not the right one.
Instead what I want is a simple equivalent to multilib_header that will also
handle abstracting executables with an appropriate wrapper that determines the
default behavior based on the users configuration. It's pretty easy to
determine what the default for the system is. (i.e. Inspect the related app, is
it 64-bit or 32-bit? Check the CC/gcc and it's default word size... etc.) If
the system really can't tell you, then the wrapper should stop with an error
telling the user it can't determine what the default is and suggest how to pass
the value for make/configure/etc.
I want a multilib_exec that can be used to generate a wrapper. The recipe will
have to pass in the name of what is being wrapped, and how to determine the
correct 'default'. The scripting should handle everything else. Like
multilib_header it needs to generate an identical script no matter when multilib
it's called with, avoiding any potential file conflict during install -- and
then an automatic rename of the underlying 'executable'... using the same logic
as multilib_header.
--Mark
>
> Alex
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-26 15:28 ` Mark Hatle
@ 2018-03-27 10:37 ` Alexander Kanavin
2018-03-27 14:38 ` Mark Hatle
0 siblings, 1 reply; 17+ messages in thread
From: Alexander Kanavin @ 2018-03-27 10:37 UTC (permalink / raw)
To: Mark Hatle, Zhang Xiao, openembedded-core
On 03/26/2018 06:28 PM, Mark Hatle wrote:
> I want a multilib_exec that can be used to generate a wrapper. The recipe will
> have to pass in the name of what is being wrapped, and how to determine the
> correct 'default'. The scripting should handle everything else. Like
> multilib_header it needs to generate an identical script no matter when multilib
> it's called with, avoiding any potential file conflict during install -- and
> then an automatic rename of the underlying 'executable'... using the same logic
> as multilib_header.
Thanks. This does look like a project that Wind River should be driving,
possibly even as a separate layer (initially). Would be good to have a
proven solution merged, rather than something half-baked with newly
discovered issues popping up down the road.
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/7] eudev: fix file conflict when multilib enabled
2018-03-27 10:37 ` Alexander Kanavin
@ 2018-03-27 14:38 ` Mark Hatle
0 siblings, 0 replies; 17+ messages in thread
From: Mark Hatle @ 2018-03-27 14:38 UTC (permalink / raw)
To: Alexander Kanavin, Zhang Xiao, openembedded-core
On 3/27/18 5:37 AM, Alexander Kanavin wrote:
> On 03/26/2018 06:28 PM, Mark Hatle wrote:
>> I want a multilib_exec that can be used to generate a wrapper. The recipe will
>> have to pass in the name of what is being wrapped, and how to determine the
>> correct 'default'. The scripting should handle everything else. Like
>> multilib_header it needs to generate an identical script no matter when multilib
>> it's called with, avoiding any potential file conflict during install -- and
>> then an automatic rename of the underlying 'executable'... using the same logic
>> as multilib_header.
>
> Thanks. This does look like a project that Wind River should be driving,
> possibly even as a separate layer (initially). Would be good to have a
> proven solution merged, rather than something half-baked with newly
> discovered issues popping up down the road.
Open for assistance from others.. but that is more or less the plan.. We (Wind
River) will be working on this as we're able.
--Mark
> Alex
>
^ permalink raw reply [flat|nested] 17+ messages in thread