[PATCH 1/3] e2fsprogs: fix multilib header conflict - ext2_types.h

[PATCH 1/3] e2fsprogs: fix multilib header conflict - ext2_types.h

[Ming Liu]

ext2_types.h conflicts between 32-bit and 64-bit versions.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
---
 meta/recipes-devtools/e2fsprogs/e2fsprogs.inc       | 3 +--
 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
index a34df37..99447c1 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
@@ -22,5 +22,4 @@ DEPENDS = "util-linux"
 SRC_URI = "${SOURCEFORGE_MIRROR}/e2fsprogs/e2fsprogs-${PV}.tar.gz \
            file://mkdir.patch"
 
-inherit autotools gettext pkgconfig
-
+inherit autotools gettext pkgconfig multilib_header
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
index 3a5d6ee..2bdd724 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
@@ -52,6 +52,8 @@ do_install () {
 		mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
 		mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
 	fi
+
+	oe_multilib_header ext2fs/ext2_types.h
 }
 
 RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
-- 
1.8.4.1

[PATCH 2/3] freetype: fix multilib header conflict - ftconfig.h

[Ming Liu]

ftconfig.h conflicts between 32-bit and 64-bit versions.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
---
 meta/recipes-graphics/freetype/freetype_2.5.2.bb | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/freetype/freetype_2.5.2.bb b/meta/recipes-graphics/freetype/freetype_2.5.2.bb
index b93453a..0c62a67 100644
--- a/meta/recipes-graphics/freetype/freetype_2.5.2.bb
+++ b/meta/recipes-graphics/freetype/freetype_2.5.2.bb
@@ -21,7 +21,7 @@ SRC_URI[sha256sum] = "4ff4bd393aa01071ec7b849d035508a505a78f88b2bcf25ff11e58e43c
 
 S = "${WORKDIR}/freetype-${PV}"
 
-inherit autotools-brokensep pkgconfig binconfig
+inherit autotools-brokensep pkgconfig binconfig multilib_header
 
 LIBTOOL = "${S}/builds/unix/${HOST_SYS}-libtool"
 EXTRA_OEMAKE = "'LIBTOOL=${LIBTOOL}'"
@@ -50,5 +50,9 @@ do_compile_prepend() {
 	${BUILD_CC} -o objs/apinames src/tools/apinames.c
 }
 
+do_install_append() {
+	oe_multilib_header freetype2/config/ftconfig.h
+}
+
 BBCLASSEXTEND = "native"
 
-- 
1.8.4.1

[PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu]

In most cases binconfig files conflict among multilib packages, to avoid
that, use update-alternatives link *-config from real path with a
PACKAGE_ARCH suffix.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
---
 meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 56 insertions(+), 9 deletions(-)

diff --git a/meta/classes/binconfig.bbclass b/meta/classes/binconfig.bbclass
index 7158c8c..c5503b7 100644
--- a/meta/classes/binconfig.bbclass
+++ b/meta/classes/binconfig.bbclass
@@ -1,4 +1,4 @@
-FILES_${PN}-dev += "${bindir}/*-config"
+FILES_${PN}-dev += "${bindir}/*-config.${PACKAGE_ARCH}"
  
 # The namespaces can clash here hence the two step replace
 def get_binconfig_mangle(d):
@@ -31,14 +31,21 @@ BINCONFIG_GLOB ?= "*-config"
 PACKAGE_PREPROCESS_FUNCS += "binconfig_package_preprocess"
 
 binconfig_package_preprocess () {
-	for config in `find ${PKGD} -name '${BINCONFIG_GLOB}'`; do
-		sed -i \
-		    -e 's:${STAGING_BASELIBDIR}:${base_libdir}:g;' \
-		    -e 's:${STAGING_LIBDIR}:${libdir}:g;' \
-		    -e 's:${STAGING_INCDIR}:${includedir}:g;' \
-		    -e 's:${STAGING_DATADIR}:${datadir}:' \
-		    -e 's:${STAGING_DIR_HOST}${prefix}:${prefix}:' \
-                    $config
+	for config in `find ${PKGD}${bindir} -name '${BINCONFIG_GLOB}'`; do
+		if [ -h $config ]; then
+			real_config=`readlink $config`
+			unlink $config
+			( cd ${PKGD}${bindir} ; ln -sf $real_config.${PACKAGE_ARCH} $config.${PACKAGE_ARCH} )
+		else
+			sed -i \
+			    -e 's:${STAGING_BASELIBDIR}:${base_libdir}:g;' \
+			    -e 's:${STAGING_LIBDIR}:${libdir}:g;' \
+			    -e 's:${STAGING_INCDIR}:${includedir}:g;' \
+			    -e 's:${STAGING_DATADIR}:${datadir}:' \
+			    -e 's:${STAGING_DIR_HOST}${prefix}:${prefix}:' \
+			    $config
+			mv $config $config.${PACKAGE_ARCH}
+		fi
 	done
 	for lafile in `find ${PKGD} -name "*.la"` ; do
 		sed -i \
@@ -51,6 +58,46 @@ binconfig_package_preprocess () {
 	done	    
 }
 
+BINCONFIG_PRIORITY ?= "${@int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.')[0]) * 10000 + \
+                       int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.')[1]) * 100 + \
+                       int(d.getVar('PV',1).split('-')[0].split('+')[0].split('.')[-1])}"
+
+PACKAGESPLITFUNCS_prepend = "populate_packages_binconfig "
+
+#
+# Fix binconfig conflicts among multilib packages
+#
+python populate_packages_binconfig () {
+    import os, glob
+
+    pkg = d.getVar('PN', True) + '-dev'
+    dvar = d.getVar('PKGD', True)
+    bindir = d.getVar('bindir', True)
+    binconfig_glob = d.getVar('BINCONFIG_GLOB', True)
+    binconfig_priority = d.getVar('BINCONFIG_PRIORITY', True)
+    binconfig_setup_links = ""
+    binconfig_remove_links = ""
+    for file in glob.glob(dvar + bindir + os.sep + binconfig_glob + '.' + d.getVar('PACKAGE_ARCH', True)):
+        binconfig_target = os.path.basename(file)
+        binconfig_name = binconfig_target[:binconfig_target.find('.')]
+        binconfig_link = bindir + os.sep + binconfig_name
+        binconfig_setup_links += '\tupdate-alternatives --install %s %s %s %s\n' % (binconfig_link, binconfig_name, binconfig_target, binconfig_priority)
+        binconfig_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (binconfig_name, binconfig_target)
+
+        if binconfig_setup_links:
+            provider = d.getVar('VIRTUAL-RUNTIME_update-alternatives', True)
+            if provider:
+                d.appendVar('RDEPENDS_%s' % pkg, ' ' + d.getVar('MLPREFIX') + provider)
+
+            postinst = d.getVar('pkg_postinst_%s' % pkg, True) or '#!/bin/sh\n'
+            postinst += binconfig_setup_links
+            d.setVar('pkg_postinst_%s' % pkg, postinst)
+
+            postrm = d.getVar('pkg_postrm_%s' % pkg, True) or '#!/bin/sh\n'
+            postrm += binconfig_remove_links
+            d.setVar('pkg_postrm_%s' % pkg, postrm)
+}
+
 SYSROOT_PREPROCESS_FUNCS += "binconfig_sysroot_preprocess"
 
 binconfig_sysroot_preprocess () {
-- 
1.8.4.1

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Richard Purdie]

On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
> In most cases binconfig files conflict among multilib packages, to avoid
> that, use update-alternatives link *-config from real path with a
> PACKAGE_ARCH suffix.
> 
> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> ---
>  meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
>  1 file changed, 56 insertions(+), 9 deletions(-)

This isn't going in, its complex and supports a minority use case.
binconfig should be dying out, not being extended and shored up like
this.

I'd also add this patch is buggy, its pure luck that update-alternatives
is available at rootfs generation time since its not in a visible
dependency.

So going forward I'd like to see patches which simply delete binconfig
scripts. Where there isn't a .pc alternative we should be adding them
and pushing them upstream.

Cheers,

Richard

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu]

On 04/07/2014 07:36 PM, Richard Purdie wrote:
> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
>> In most cases binconfig files conflict among multilib packages, to avoid
>> that, use update-alternatives link *-config from real path with a
>> PACKAGE_ARCH suffix.
>>
>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
>> ---
>>   meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
>>   1 file changed, 56 insertions(+), 9 deletions(-)
> This isn't going in, its complex and supports a minority use case.
> binconfig should be dying out, not being extended and shored up like
> this.
>
> I'd also add this patch is buggy, its pure luck that update-alternatives
> is available at rootfs generation time since its not in a visible
> dependency.
>
> So going forward I'd like to see patches which simply delete binconfig
> scripts. Where there isn't a .pc alternative we should be adding them
> and pushing them upstream.
Did you mean we'd better remove all *-config scripts, insteaded by 
providing .pc files, and send the changes to all upstreams providing and 
using *-config? That seems a huge work and we need co-operate with a lot 
of projects.

//Ming Liu
>
> Cheers,
>
> Richard
>
>
>
>
>

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Richard Purdie]

On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
> On 04/07/2014 07:36 PM, Richard Purdie wrote:
> > On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
> >> In most cases binconfig files conflict among multilib packages, to avoid
> >> that, use update-alternatives link *-config from real path with a
> >> PACKAGE_ARCH suffix.
> >>
> >> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> >> ---
> >>   meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
> >>   1 file changed, 56 insertions(+), 9 deletions(-)
> > This isn't going in, its complex and supports a minority use case.
> > binconfig should be dying out, not being extended and shored up like
> > this.
> >
> > I'd also add this patch is buggy, its pure luck that update-alternatives
> > is available at rootfs generation time since its not in a visible
> > dependency.
> >
> > So going forward I'd like to see patches which simply delete binconfig
> > scripts. Where there isn't a .pc alternative we should be adding them
> > and pushing them upstream.
> Did you mean we'd better remove all *-config scripts, insteaded by 
> providing .pc files, and send the changes to all upstreams providing and 
> using *-config? That seems a huge work and we need co-operate with a lot 
> of projects.

Basically, yes, that is what I mean. I might be wrong but I don't think
there are that many projects which don't ship .pc files now and just
have a binconfig as a backup.

Cheers,

Richard

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu]

On 04/08/2014 06:03 PM, Richard Purdie wrote:
> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
>>>> In most cases binconfig files conflict among multilib packages, to avoid
>>>> that, use update-alternatives link *-config from real path with a
>>>> PACKAGE_ARCH suffix.
>>>>
>>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
>>>> ---
>>>>    meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
>>>>    1 file changed, 56 insertions(+), 9 deletions(-)
>>> This isn't going in, its complex and supports a minority use case.
>>> binconfig should be dying out, not being extended and shored up like
>>> this.
>>>
>>> I'd also add this patch is buggy, its pure luck that update-alternatives
>>> is available at rootfs generation time since its not in a visible
>>> dependency.
>>>
>>> So going forward I'd like to see patches which simply delete binconfig
>>> scripts. Where there isn't a .pc alternative we should be adding them
>>> and pushing them upstream.
>> Did you mean we'd better remove all *-config scripts, insteaded by
>> providing .pc files, and send the changes to all upstreams providing and
>> using *-config? That seems a huge work and we need co-operate with a lot
>> of projects.
> Basically, yes, that is what I mean. I might be wrong but I don't think
> there are that many projects which don't ship .pc files now and just
> have a binconfig as a backup.
Yes, I also noticed that many of them are providing .pc files as well as 
binconfig as a backup, so I think there must be reasons binconfig 
remained in their projects, that might be for compliable considering,  
so I am not sure they would like to remove them from their projects, but 
I can try to ping them. Nevertheless, the conflicts still exist, we just 
leave them here so far?

//Ming Liu
>
> Cheers,
>
> Richard
>
>
>
>

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Richard Purdie]

On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
> On 04/08/2014 06:03 PM, Richard Purdie wrote:
> > On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
> >> On 04/07/2014 07:36 PM, Richard Purdie wrote:
> >>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
> >>>> In most cases binconfig files conflict among multilib packages, to avoid
> >>>> that, use update-alternatives link *-config from real path with a
> >>>> PACKAGE_ARCH suffix.
> >>>>
> >>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> >>>> ---
> >>>>    meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
> >>>>    1 file changed, 56 insertions(+), 9 deletions(-)
> >>> This isn't going in, its complex and supports a minority use case.
> >>> binconfig should be dying out, not being extended and shored up like
> >>> this.
> >>>
> >>> I'd also add this patch is buggy, its pure luck that update-alternatives
> >>> is available at rootfs generation time since its not in a visible
> >>> dependency.
> >>>
> >>> So going forward I'd like to see patches which simply delete binconfig
> >>> scripts. Where there isn't a .pc alternative we should be adding them
> >>> and pushing them upstream.
> >> Did you mean we'd better remove all *-config scripts, insteaded by
> >> providing .pc files, and send the changes to all upstreams providing and
> >> using *-config? That seems a huge work and we need co-operate with a lot
> >> of projects.
> > Basically, yes, that is what I mean. I might be wrong but I don't think
> > there are that many projects which don't ship .pc files now and just
> > have a binconfig as a backup.
> Yes, I also noticed that many of them are providing .pc files as well as 
> binconfig as a backup, so I think there must be reasons binconfig 
> remained in their projects, that might be for compliable considering,  
> so I am not sure they would like to remove them from their projects, but 
> I can try to ping them. Nevertheless, the conflicts still exist, we just 
> leave them here so far?

I'm thinking we should start deleting the -config files at do_install
time where we know a good .pc file exists and remove the binconfig
inherit. If this causes any problem in software using the package, we
should fix those to use pkgconfig.

Over time the conflicts will stop existing since the binconfig class
will not be used anywhere.

Cheers,

Richard

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu]

On 04/09/2014 05:42 PM, Richard Purdie wrote:
> On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
>> On 04/08/2014 06:03 PM, Richard Purdie wrote:
>>> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
>>>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
>>>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
>>>>>> In most cases binconfig files conflict among multilib packages, to avoid
>>>>>> that, use update-alternatives link *-config from real path with a
>>>>>> PACKAGE_ARCH suffix.
>>>>>>
>>>>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
>>>>>> ---
>>>>>>     meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
>>>>>>     1 file changed, 56 insertions(+), 9 deletions(-)
>>>>> This isn't going in, its complex and supports a minority use case.
>>>>> binconfig should be dying out, not being extended and shored up like
>>>>> this.
>>>>>
>>>>> I'd also add this patch is buggy, its pure luck that update-alternatives
>>>>> is available at rootfs generation time since its not in a visible
>>>>> dependency.
>>>>>
>>>>> So going forward I'd like to see patches which simply delete binconfig
>>>>> scripts. Where there isn't a .pc alternative we should be adding them
>>>>> and pushing them upstream.
>>>> Did you mean we'd better remove all *-config scripts, insteaded by
>>>> providing .pc files, and send the changes to all upstreams providing and
>>>> using *-config? That seems a huge work and we need co-operate with a lot
>>>> of projects.
>>> Basically, yes, that is what I mean. I might be wrong but I don't think
>>> there are that many projects which don't ship .pc files now and just
>>> have a binconfig as a backup.
>> Yes, I also noticed that many of them are providing .pc files as well as
>> binconfig as a backup, so I think there must be reasons binconfig
>> remained in their projects, that might be for compliable considering,
>> so I am not sure they would like to remove them from their projects, but
>> I can try to ping them. Nevertheless, the conflicts still exist, we just
>> leave them here so far?
> I'm thinking we should start deleting the -config files at do_install
> time where we know a good .pc file exists and remove the binconfig
> inherit. If this causes any problem in software using the package, we
> should fix those to use pkgconfig.
>
> Over time the conflicts will stop existing since the binconfig class
> will not be used anywhere.
Yes, that's a feasible solution, but it needs a lot of testing works, 
unfortunately, I am a little busy with my daily work recently and cant 
handle it parallelly, so I'd like to file a bug in Yocto, see if anybody 
like to take it, or I will do it when I can tear myself away from work 
later.

//Ming Liu
>
> Cheers,
>
> Richard
>
>
>
>
>

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu]

On 04/09/2014 06:01 PM, Ming Liu wrote:
> On 04/09/2014 05:42 PM, Richard Purdie wrote:
>> On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
>>> On 04/08/2014 06:03 PM, Richard Purdie wrote:
>>>> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
>>>>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
>>>>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
>>>>>>> In most cases binconfig files conflict among multilib packages, 
>>>>>>> to avoid
>>>>>>> that, use update-alternatives link *-config from real path with a
>>>>>>> PACKAGE_ARCH suffix.
>>>>>>>
>>>>>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
>>>>>>> ---
>>>>>>>     meta/classes/binconfig.bbclass | 65 
>>>>>>> ++++++++++++++++++++++++++++++++++++------
>>>>>>>     1 file changed, 56 insertions(+), 9 deletions(-)
>>>>>> This isn't going in, its complex and supports a minority use case.
>>>>>> binconfig should be dying out, not being extended and shored up like
>>>>>> this.
>>>>>>
>>>>>> I'd also add this patch is buggy, its pure luck that 
>>>>>> update-alternatives
>>>>>> is available at rootfs generation time since its not in a visible
>>>>>> dependency.
>>>>>>
>>>>>> So going forward I'd like to see patches which simply delete 
>>>>>> binconfig
>>>>>> scripts. Where there isn't a .pc alternative we should be adding 
>>>>>> them
>>>>>> and pushing them upstream.
>>>>> Did you mean we'd better remove all *-config scripts, insteaded by
>>>>> providing .pc files, and send the changes to all upstreams 
>>>>> providing and
>>>>> using *-config? That seems a huge work and we need co-operate with 
>>>>> a lot
>>>>> of projects.
>>>> Basically, yes, that is what I mean. I might be wrong but I don't 
>>>> think
>>>> there are that many projects which don't ship .pc files now and just
>>>> have a binconfig as a backup.
>>> Yes, I also noticed that many of them are providing .pc files as 
>>> well as
>>> binconfig as a backup, so I think there must be reasons binconfig
>>> remained in their projects, that might be for compliable considering,
>>> so I am not sure they would like to remove them from their projects, 
>>> but
>>> I can try to ping them. Nevertheless, the conflicts still exist, we 
>>> just
>>> leave them here so far?
>> I'm thinking we should start deleting the -config files at do_install
>> time where we know a good .pc file exists and remove the binconfig
>> inherit. If this causes any problem in software using the package, we
>> should fix those to use pkgconfig.
>>
>> Over time the conflicts will stop existing since the binconfig class
>> will not be used anywhere.
> Yes, that's a feasible solution, but it needs a lot of testing works, 
> unfortunately, I am a little busy with my daily work recently and cant 
> handle it parallelly, so I'd like to file a bug in Yocto, see if 
> anybody like to take it, or I will do it when I can tear myself away 
> from work later.
Seems we already have the defect record, and Qi Chen has been working on 
that for a while, see the following:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2453

//Ming Liu
>
> //Ming Liu
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>>
>

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Richard Purdie]

On Wed, 2014-04-09 at 18:07 +0800, Ming Liu wrote:
> On 04/09/2014 06:01 PM, Ming Liu wrote:
> > On 04/09/2014 05:42 PM, Richard Purdie wrote:
> >> On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
> >>> On 04/08/2014 06:03 PM, Richard Purdie wrote:
> >>>> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
> >>>>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
> >>>>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
> >>>>>>> In most cases binconfig files conflict among multilib packages, 
> >>>>>>> to avoid
> >>>>>>> that, use update-alternatives link *-config from real path with a
> >>>>>>> PACKAGE_ARCH suffix.
> >>>>>>>
> >>>>>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> >>>>>>> ---
> >>>>>>>     meta/classes/binconfig.bbclass | 65 
> >>>>>>> ++++++++++++++++++++++++++++++++++++------
> >>>>>>>     1 file changed, 56 insertions(+), 9 deletions(-)
> >>>>>> This isn't going in, its complex and supports a minority use case.
> >>>>>> binconfig should be dying out, not being extended and shored up like
> >>>>>> this.
> >>>>>>
> >>>>>> I'd also add this patch is buggy, its pure luck that 
> >>>>>> update-alternatives
> >>>>>> is available at rootfs generation time since its not in a visible
> >>>>>> dependency.
> >>>>>>
> >>>>>> So going forward I'd like to see patches which simply delete 
> >>>>>> binconfig
> >>>>>> scripts. Where there isn't a .pc alternative we should be adding 
> >>>>>> them
> >>>>>> and pushing them upstream.
> >>>>> Did you mean we'd better remove all *-config scripts, insteaded by
> >>>>> providing .pc files, and send the changes to all upstreams 
> >>>>> providing and
> >>>>> using *-config? That seems a huge work and we need co-operate with 
> >>>>> a lot
> >>>>> of projects.
> >>>> Basically, yes, that is what I mean. I might be wrong but I don't 
> >>>> think
> >>>> there are that many projects which don't ship .pc files now and just
> >>>> have a binconfig as a backup.
> >>> Yes, I also noticed that many of them are providing .pc files as 
> >>> well as
> >>> binconfig as a backup, so I think there must be reasons binconfig
> >>> remained in their projects, that might be for compliable considering,
> >>> so I am not sure they would like to remove them from their projects, 
> >>> but
> >>> I can try to ping them. Nevertheless, the conflicts still exist, we 
> >>> just
> >>> leave them here so far?
> >> I'm thinking we should start deleting the -config files at do_install
> >> time where we know a good .pc file exists and remove the binconfig
> >> inherit. If this causes any problem in software using the package, we
> >> should fix those to use pkgconfig.
> >>
> >> Over time the conflicts will stop existing since the binconfig class
> >> will not be used anywhere.
> > Yes, that's a feasible solution, but it needs a lot of testing works, 
> > unfortunately, I am a little busy with my daily work recently and cant 
> > handle it parallelly, so I'd like to file a bug in Yocto, see if 
> > anybody like to take it, or I will do it when I can tear myself away 
> > from work later.
> Seems we already have the defect record, and Qi Chen has been working on 
> that for a while, see the following:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2453

That bug suggests we have .pc files for all -config files. We would
therefore next need to follow through and remove all the -config files
entirely and just rely on the .pc files. We should open an enhancement
request for that.

Cheers,

Richard

Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Richard Purdie]

On Wed, 2014-04-09 at 18:01 +0800, Ming Liu wrote:
> On 04/09/2014 05:42 PM, Richard Purdie wrote:
> > On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
> >> On 04/08/2014 06:03 PM, Richard Purdie wrote:
> >>> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
> >>>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
> >>>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
> >>>>>> In most cases binconfig files conflict among multilib packages, to avoid
> >>>>>> that, use update-alternatives link *-config from real path with a
> >>>>>> PACKAGE_ARCH suffix.
> >>>>>>
> >>>>>> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> >>>>>> ---
> >>>>>>     meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
> >>>>>>     1 file changed, 56 insertions(+), 9 deletions(-)
> >>>>> This isn't going in, its complex and supports a minority use case.
> >>>>> binconfig should be dying out, not being extended and shored up like
> >>>>> this.
> >>>>>
> >>>>> I'd also add this patch is buggy, its pure luck that update-alternatives
> >>>>> is available at rootfs generation time since its not in a visible
> >>>>> dependency.
> >>>>>
> >>>>> So going forward I'd like to see patches which simply delete binconfig
> >>>>> scripts. Where there isn't a .pc alternative we should be adding them
> >>>>> and pushing them upstream.
> >>>> Did you mean we'd better remove all *-config scripts, insteaded by
> >>>> providing .pc files, and send the changes to all upstreams providing and
> >>>> using *-config? That seems a huge work and we need co-operate with a lot
> >>>> of projects.
> >>> Basically, yes, that is what I mean. I might be wrong but I don't think
> >>> there are that many projects which don't ship .pc files now and just
> >>> have a binconfig as a backup.
> >> Yes, I also noticed that many of them are providing .pc files as well as
> >> binconfig as a backup, so I think there must be reasons binconfig
> >> remained in their projects, that might be for compliable considering,
> >> so I am not sure they would like to remove them from their projects, but
> >> I can try to ping them. Nevertheless, the conflicts still exist, we just
> >> leave them here so far?
> > I'm thinking we should start deleting the -config files at do_install
> > time where we know a good .pc file exists and remove the binconfig
> > inherit. If this causes any problem in software using the package, we
> > should fix those to use pkgconfig.
> >
> > Over time the conflicts will stop existing since the binconfig class
> > will not be used anywhere.
> Yes, that's a feasible solution, but it needs a lot of testing works, 
> unfortunately, I am a little busy with my daily work recently and cant 
> handle it parallelly, so I'd like to file a bug in Yocto, see if anybody 
> like to take it, or I will do it when I can tear myself away from work 
> later.

Agreed, I'm not asking you personally to do all of this, just suggesting
that ultimately this is the route we need to take.

Cheers,

Richard

Re: [PATCH 1/3] e2fsprogs: fix multilib header conflict - ext2_types.h

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Apr 7, 2014 1:28 AM, "Ming Liu" <ming.liu@windriver.com> wrote:
>
> ext2_types.h conflicts between 32-bit and 64-bit versions.
>

can you explain the conflicts
may be they can be addressed

> Signed-off-by: Ming Liu <ming.liu@windriver.com>
> ---
>  meta/recipes-devtools/e2fsprogs/e2fsprogs.inc       | 3 +--
>  meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 2 ++
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> index a34df37..99447c1 100644
> --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> @@ -22,5 +22,4 @@ DEPENDS = "util-linux"
>  SRC_URI = "${SOURCEFORGE_MIRROR}/e2fsprogs/e2fsprogs-${PV}.tar.gz \
>             file://mkdir.patch"
>
> -inherit autotools gettext pkgconfig
> -
> +inherit autotools gettext pkgconfig multilib_header
> diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bbb/meta/recipes-devtools/e2fsprogs/
e2fsprogs_1.42.9.bb
> index 3a5d6ee..2bdd724 100644
> --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
> +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb
> @@ -52,6 +52,8 @@ do_install () {
>                 mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
>                 mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
>         fi
> +
> +       oe_multilib_header ext2fs/ext2_types.h
>  }
>
>  RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> --
> 1.8.4.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 2636 bytes --]

Re: [PATCH 1/3] e2fsprogs: fix multilib header conflict - ext2_types.h

[Ming Liu]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

On 04/08/2014 03:50 AM, Khem Raj wrote:
>
>
> On Apr 7, 2014 1:28 AM, "Ming Liu" <ming.liu@windriver.com 
> <mailto:ming.liu@windriver.com>> wrote:
> >
> > ext2_types.h conflicts between 32-bit and 64-bit versions.
> >
>
> can you explain the conflicts
> may be they can be addressed
>
Yes, of course, see the following diff output of 64bits and 32bits 
ext2_types.h :
diff -urpN /tmp/64bits/ext2_types.h /tmp/32bits/ext2_types.h
--- /tmp/64bits/ext2_types.h
+++ /tmp/32bits/ext2_types.h
@@ -63,7 +63,7 @@ typedef __U32_TYPEDEF __u32;
  #if (4 == 4)
  typedef    unsigned int    __u32;
  #else
-#if (8 == 4)
+#if (4 == 4)
  typedef    unsigned long    __u32;
  #else
  #if (2 == 4)
@@ -81,7 +81,7 @@ typedef __S32_TYPEDEF __s32;
  #if (4 == 4)
  typedef    int        __s32;
  #else
-#if (8 == 4)
+#if (4 == 4)
  typedef    long        __s32;
  #else
  #if (2 == 4)
@@ -102,7 +102,7 @@ typedef unsigned int    __u64;
  #if (8 == 8)
  typedef unsigned long long    __u64;
  #else
-#if (8 == 8)
+#if (4 == 8)
  typedef unsigned long    __u64;
  #endif /* SIZEOF_LONG_LONG == 8 */
  #endif /* SIZEOF_LONG == 8 */
@@ -122,7 +122,7 @@ typedef __signed__ long long    __s64;
  typedef signed long long    __s64;
  #endif /* __GNUC__ */
  #else
-#if (8 == 8)
+#if (4 == 8)
  typedef long        __s64;
  #endif /* SIZEOF_LONG_LONG == 8 */
  #endif /* SIZEOF_LONG == 8 */

ext2_types.h conflicts between 32-bit and 64-bit versions.

//Ming Liu
>
> > Signed-off-by: Ming Liu <ming.liu@windriver.com 
> <mailto:ming.liu@windriver.com>>
> > ---
> >  meta/recipes-devtools/e2fsprogs/e2fsprogs.inc       | 3 +--
> >  meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb 
> <http://e2fsprogs_1.42.9.bb> | 2 ++
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc 
> b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> > index a34df37..99447c1 100644
> > --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> > +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs.inc
> > @@ -22,5 +22,4 @@ DEPENDS = "util-linux"
> >  SRC_URI = "${SOURCEFORGE_MIRROR}/e2fsprogs/e2fsprogs-${PV}.tar.gz \
> >             file://mkdir.patch"
> >
> > -inherit autotools gettext pkgconfig
> > -
> > +inherit autotools gettext pkgconfig multilib_header
> > diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb 
> <http://e2fsprogs_1.42.9.bb> 
> b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb 
> <http://e2fsprogs_1.42.9.bb>
> > index 3a5d6ee..2bdd724 100644
> > --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb 
> <http://e2fsprogs_1.42.9.bb>
> > +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb 
> <http://e2fsprogs_1.42.9.bb>
> > @@ -52,6 +52,8 @@ do_install () {
> >                 mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
> >                 mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
> >         fi
> > +
> > +       oe_multilib_header ext2fs/ext2_types.h
> >  }
> >
> >  RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> > --
> > 1.8.4.1
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org 
> <mailto:Openembedded-core@lists.openembedded.org>
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


[-- Attachment #2: Type: text/html, Size: 5614 bytes --]