[oe] vdr: minimal-uclibc: task `compile` fails with `undefined reference to `_nl_msg_cat_cntr'`

[Bernhard Reutner-Fischer]

"Paul Menzel" <paulepanter at users.sourceforge.net> wrote:

>Am Samstag, den 22.01.2011, 09:17 +0100 schrieb Paul Menzel:
>> Am Samstag, den 22.01.2011, 00:39 +0100 schrieb Paul Menzel:
>> > Am Freitag, den 21.01.2011, 10:10 -0800 schrieb Khem Raj:
>> > > On Fri, Jan 21, 2011 at 3:22 AM, Paul Menzel wrote:
>> > > >
>> > > > `bitbake -k vdr` was executed with 6db34075 (uClibc 0.9.32-rc2)
>[1] and
>> > > > `minimal-uclibc` for `MACHINE = "beagleboard"`. I guess it is
>related to
>> > > > the uClibc upgrade.
>> > > >
>> > > 
>> > > Did it work before this? I guess not. Upgrade has nothing to do
>with
>> > > it. Its gettext/libiconv issue in the faulty recipe itself I
>believe
>> > 
>> > I just reset to when the recipe was updated [1].
>> > 
>> >         commit f4f7638828b0e06fa7ae37ccba0e1ec294b5c30a
>> >         Author:     Paul Menzel <paulepanter at users.sourceforge.net>
>> >         AuthorDate: Mon Jul 12 21:32:52 2010 +0200
>> >         Commit:     Khem Raj <raj.khem at gmail.com>
>> >         CommitDate: Wed Jan 12 00:05:25 2011 -0800
>> >         
>> >             vdr: update to 1.7.16 from 1.7.10
>> > 
>> > It built fine. Any thoughts?
>> > 
>> > I will try to pinpoint the faulty commit. I am trying to build with
>> > 2a7ddea6 [2] next, which is the commit before the last change to
>the VDR
>> > recipe.
>> 
>> That failed already. Now I will try 260f78b3 y[3].
>
>s/already/also/
>
>The commit since when building fails is a88aca1d [6].
>
>        commit a88aca1d7dfa3a08957dd49cb61bac850f197106
>        Author: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
>        Date:   Wed Jan 12 20:34:55 2011 +0100
>        
>            autotools.bbclass: pass distro_imposed_configure_flags
>            
>            Acked-by: Khem Raj <raj.khem at gmail.com>
>            Acked-by: Tom Rini <tom_rini at mentor.com>
>        Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
>
>Any idea?
>
>
>Thanks,
>
>Paul
>
>
>> > [1]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=f4f7638828b0e06fa7ae37ccba0e1ec294b5c30a
>> > [2]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=2a7ddea6f7cd12f88a086e9d3e9228008a102248
>> [3]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=260f78b3e5b171fea66fe7c901f489ea713d2988
>[4]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=3de42fccb9d8baa70e37dbdbf8bedf5ecafb9a4d
>(fails)
>[5]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=67d127a52d6565bc90f49e2bff5de80db85b2021
>(works)
>[6]
>http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=a88aca1d7dfa3a08957dd49cb61bac850f197106
>(fails)

Hi Paul,

I will have a look as soon as I am near a computer.
You could see which of nls, ipv6 or largefile configure options trigger. If it is nls then I suspect the intl-proxy package setting (or something such) is set incorrectly.