[OE-core] glib-2.0 fails to configure with USE_NLS="no"

[Burton, Ross]

Another fix would be to respect USE_NLS and seed msgfmt=/bin/false
appropriately.  I'll test that later, or you can get the glory if you can
send a tested patch.

Ross

On 16 January 2018 at 13:58, Burton, Ross <ross.burton at intel.com> wrote:

> I've got a local patch that does this in the glib recipe:
>
> USE_NLS_class-target = "yes"
> USE_NLS_class-nativesdk = "yes"
>
> Can you verify this fixes the problem for you?
>
> Ross
>
> On 16 January 2018 at 13:56, Burton, Ross <ross.burton at intel.com> wrote:
>
>> GLib doesn't really support disable-nls, no.  I guess we need to force it
>> on for target builds, as I now hack it to work without gettext for native.
>>
>> Ross
>>
>> On 16 January 2018 at 11:55, Mike Crowe <mac at mcrowe.com> wrote:
>>
>>> On 15 January 2018 at 17:53, Mike Crowe <mac at mcrowe.com> wrote:
>>> >> If I add USE_NLS = "no" to local.conf, then glib-2.0 fails to
>>> configure:
>>> >>
>>> >> | checking for ngettext in libc... yes
>>> >> | checking for dgettext in libc... yes
>>> >> | checking for bind_textdomain_codeset... (cached) yes
>>> >> | checking for msgfmt... no
>>> >> | configure: error:
>>> >> | *** You must have either have gettext support in your C library, or
>>> use
>>> >> | the
>>> >> | *** GNU gettext library.
>>> >> | (http://www.gnu.org/software/gettext/gettext.html)
>>> >>
>>> >> It seems that glib-2.0 does not support --disable-nls and always
>>> requires
>>> >> gettext.
>>> >>
>>> >> I can avoid this error by adding gettext-native to glib-2.0's
>>> DEPENDS, but
>>> >> I'm not sure whether this is solution would be acceptable.
>>> >>
>>> >> Is there a better way?
>>>
>>> On Monday 15 January 2018 at 19:34:35 +0000, Burton, Ross wrote:
>>> > Have a look at what just landed in master...
>>>
>>> Perhaps I'm being stupid, but it looks like nothing has landed on master
>>> since Sunday.
>>>
>>> Looking at the history, I see 1ef45d377519983df827650cd0913e0d2c8a785b ,
>>> but I already had that change. Reverting it does appear to fix the
>>> problem
>>> though. Is that what you meant? If not, please can you point me at the
>>> commit you are referring to?
>>>
>>> Thanks.
>>>
>>> Mike.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180116/ac0adff4/attachment-0002.html>