Using TCLIBC = "uclibc" in oe-core

Using TCLIBC = "uclibc" in oe-core

[Tom Parkin]

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

Hi list,

I'm trying to set up a working openembedded-core/uClibc mipsel
environment.  I found that setting TCLIBC = "uclibc" in local.conf
yielded the following:

ERROR: Nothing PROVIDES 'glib-2.0-native'

I traced this down to code in meta/recipes-core/glib-2.0/glib-2.0.inc,
which raises a SkipPackage exception if USE_NLS = "no".

The reason that USE_NLS = "no" in this case is that
meta/conf/distro/include/tclibc-uclibc.inc sets USE_NLS ?= "no".

Looking further at tclibc-uclibc.inc, though, it appears that there is
some code attempting to work around this issue:

USE_NLS_glib-2.0 = "yes"

Sadly, this appears to get ignored.  Following this up on the #yocto
IRC channel, it seems that a more appropriate formulation of the above
would be:

USE_NLS_pn-glib-2.0-native = "yes"

The attached patch allows me to (at least) assemble the bitbake task
list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
approach, though.

Any comments?

Many thanks,
Tom
-- 
Tom Parkin
Senior Software Engineer
Pace Plc

Bringing Technology Home

Victoria Road, Saltaire, West Yorkshire, BD18 3LF, United Kingdom. www.pace.com

Think before you print! Please consider the environment before printing this e-mail.


This message has been scanned for viruses by BlackSpider MailControl. - www.blackspider.com

[-- Attachment #2: 0001-Override-USE_NLS-for-glib-2.0-native-when-using-uCli.patch --]
[-- Type: text/plain, Size: 1136 bytes --]

From 7cab67af78f73408d7d86f7cfce78715cd32ae6b Mon Sep 17 00:00:00 2001
From: Tom Parkin <tom.parkin@pace.com>
Date: Tue, 21 Jun 2011 14:33:22 +0100
Subject: [PATCH] Override USE_NLS for glib-2.0-native when using uClibc

We don't use NLS for uClibc, but glib-2.0-native refuses to build
if USE_NLS is not "yes" (ref. meta/recipes-core/glib-2.0/glib-2.0.inc).

As a cunning work around, override USE_NLS for glib-2.0-native.  This
allows initial bitbake tasklist parsing and assembly to complete
successfully.
---
 meta/conf/distro/include/tclibc-uclibc.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
index c421f5e..408966b 100644
--- a/meta/conf/distro/include/tclibc-uclibc.inc
+++ b/meta/conf/distro/include/tclibc-uclibc.inc
@@ -14,7 +14,7 @@ PREFERRED_PROVIDER_virtual/libiconv ?= "libiconv"
 PREFERRED_PROVIDER_virtual/libintl ?= "gettext"
 
 USE_NLS ?= "no"
-USE_NLS_glib-2.0 = "yes"
+USE_NLS_pn-glib-2.0-native = "yes"
 
 CXXFLAGS += "-fvisibility-inlines-hidden"
 
-- 
1.7.4.4

Re: Using TCLIBC = "uclibc" in oe-core

[Khem Raj]

On 06/21/2011 07:04 AM, Tom Parkin wrote:
> Hi list,
>
> I'm trying to set up a working openembedded-core/uClibc mipsel
> environment.  I found that setting TCLIBC = "uclibc" in local.conf
> yielded the following:
>
> ERROR: Nothing PROVIDES 'glib-2.0-native'
>
> I traced this down to code in meta/recipes-core/glib-2.0/glib-2.0.inc,
> which raises a SkipPackage exception if USE_NLS = "no".
>
> The reason that USE_NLS = "no" in this case is that
> meta/conf/distro/include/tclibc-uclibc.inc sets USE_NLS ?= "no".
>
> Looking further at tclibc-uclibc.inc, though, it appears that there is
> some code attempting to work around this issue:
>
> USE_NLS_glib-2.0 = "yes"
>
> Sadly, this appears to get ignored.  Following this up on the #yocto
> IRC channel, it seems that a more appropriate formulation of the above
> would be:
>
> USE_NLS_pn-glib-2.0-native = "yes"
>
> The attached patch allows me to (at least) assemble the bitbake task
> list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
> approach, though.
>
> Any comments?

Yes this seems to be ok. If you look into angstrom distribution then it
already has it in its distro config files

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/tree/conf/distro/include/angstrom-uclibc.inc

but probably putting it in core would be appropriate.
>
> Many thanks,
> Tom
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Using TCLIBC = "uclibc" in oe-core

[Mark Hatle]

On 6/21/11 9:04 AM, Tom Parkin wrote:
> Hi list,
> 
> I'm trying to set up a working openembedded-core/uClibc mipsel
> environment.  I found that setting TCLIBC = "uclibc" in local.conf
> yielded the following:
> 
> ERROR: Nothing PROVIDES 'glib-2.0-native'
> 
> I traced this down to code in meta/recipes-core/glib-2.0/glib-2.0.inc,
> which raises a SkipPackage exception if USE_NLS = "no".

Sounds like this should behave differently for the glib-2.0-native and glib-2.0
target.  I don't know how to detect the package type in python code though,
someone else might know.

--Mark

> The reason that USE_NLS = "no" in this case is that
> meta/conf/distro/include/tclibc-uclibc.inc sets USE_NLS ?= "no".
> 
> Looking further at tclibc-uclibc.inc, though, it appears that there is
> some code attempting to work around this issue:
> 
> USE_NLS_glib-2.0 = "yes"
> 
> Sadly, this appears to get ignored.  Following this up on the #yocto
> IRC channel, it seems that a more appropriate formulation of the above
> would be:
> 
> USE_NLS_pn-glib-2.0-native = "yes"
> 
> The attached patch allows me to (at least) assemble the bitbake task
> list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
> approach, though.
> 
> Any comments?
> 
> Many thanks,
> Tom
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Using TCLIBC = "uclibc" in oe-core

[Phil Blundell]

On Tue, 2011-06-21 at 15:04 +0100, Tom Parkin wrote:
> The attached patch allows me to (at least) assemble the bitbake task
> list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
> approach, though.

Do you know why glib-2.0.inc is doing this crazy thing in the first
place?  If we're going to have code in the config files to effectively
make it think that USE_NLS is always on, maybe that check should just be
removed.

You're right though that the current line in tclibc-uclibc.inc is
clearly just wrong and should be either fixed or deleted.

p.

Re: Using TCLIBC = "uclibc" in oe-core

[Khem Raj]

On 06/21/2011 07:54 AM, Phil Blundell wrote:
> On Tue, 2011-06-21 at 15:04 +0100, Tom Parkin wrote:
>> The attached patch allows me to (at least) assemble the bitbake task
>> list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
>> approach, though.
>
> Do you know why glib-2.0.inc is doing this crazy thing in the first
> place?  If we're going to have code in the config files to effectively
> make it think that USE_NLS is always on, maybe that check should just be
> removed.
>
> You're right though that the current line in tclibc-uclibc.inc is
> clearly just wrong and should be either fixed or deleted.
>

Yes and another issue is USE_NLS settings applies to native recipes as 
well. The intention is to just have it for target recipes. May be 
native.bbclass
should forcibly set this var to yes unless someone is building on uclibc
build systems which would be rare.

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Using TCLIBC = "uclibc" in oe-core

[Richard Purdie]

On Tue, 2011-06-21 at 15:54 +0100, Phil Blundell wrote:
> On Tue, 2011-06-21 at 15:04 +0100, Tom Parkin wrote:
> > The attached patch allows me to (at least) assemble the bitbake task
> > list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
> > approach, though.
> 
> Do you know why glib-2.0.inc is doing this crazy thing in the first
> place?  If we're going to have code in the config files to effectively
> make it think that USE_NLS is always on, maybe that check should just be
> removed.
> 
> You're right though that the current line in tclibc-uclibc.inc is
> clearly just wrong and should be either fixed or deleted.

It does appear to work due to code in base.bbclass which does:

    use_nls = bb.data.getVar('USE_NLS_%s' % pn, d, 1)
    if use_nls != None:
        bb.data.setVar('USE_NLS', use_nls, d)

where this code predates the use of pn-${PN} in overrides.

Nowadays it makes sense just to use the pn- override and we should drop
this legacy stuff IMO.

Cheers,

Richard

Re: Using TCLIBC = "uclibc" in oe-core

[Tom Parkin]

Thanks for the comments, everyone.

I think the balance of what's been said suggests we'd want this change
in oe-core.  The question of whether doing special "USE_NLS" hackery
for glib-2.0-native is a good design or not is a somewhat more open
issue...

Assuming this change is good, what would I need to do to formally
submit a patch?  Is there a howto for oe-core patch submission that I
can refer to?

Thanks,
Tom

On 21 June 2011 17:49, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2011-06-21 at 15:54 +0100, Phil Blundell wrote:
>> On Tue, 2011-06-21 at 15:04 +0100, Tom Parkin wrote:
>> > The attached patch allows me to (at least) assemble the bitbake task
>> > list when TCLIBC = "uclibc".  I'm not sure whether this is the correct
>> > approach, though.
>>
>> Do you know why glib-2.0.inc is doing this crazy thing in the first
>> place?  If we're going to have code in the config files to effectively
>> make it think that USE_NLS is always on, maybe that check should just be
>> removed.
>>
>> You're right though that the current line in tclibc-uclibc.inc is
>> clearly just wrong and should be either fixed or deleted.
>
> It does appear to work due to code in base.bbclass which does:
>
>    use_nls = bb.data.getVar('USE_NLS_%s' % pn, d, 1)
>    if use_nls != None:
>        bb.data.setVar('USE_NLS', use_nls, d)
>
> where this code predates the use of pn-${PN} in overrides.
>
> Nowadays it makes sense just to use the pn- override and we should drop
> this legacy stuff IMO.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
Tom Parkin
www.thesecretdogproject.com
Morality, like art, means drawing a line someplace /Wilde/