Patchwork Using TCLIBC = "uclibc" in oe-core

login
register
mail settings
Submitter Tom Parkin
Date June 21, 2011, 2:04 p.m.
Message ID <20110621140419.GA8589@raven.pace.internal>
Download mbox | patch
Permalink /patch/6177/
State New, archived
Headers show

Comments

Tom Parkin - June 21, 2011, 2:04 p.m.
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
Khem Raj - June 21, 2011, 2:50 p.m.
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
Mark Hatle - June 21, 2011, 2:53 p.m.
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
Phil Blundell - June 21, 2011, 2:54 p.m.
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.
Khem Raj - June 21, 2011, 3:02 p.m.
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
Richard Purdie - June 21, 2011, 4:49 p.m.
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
Tom Parkin - June 22, 2011, 1:13 p.m.
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
>

Patch

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"