[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] lib/gettext.h: fix warning if gettext is already present

From: Giulio Benetti
Subject: Re: [PATCH] lib/gettext.h: fix warning if gettext is already present
Date: Mon, 3 Feb 2020 00:15:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Hi Bruno,

On 1/27/20 8:29 PM, Bruno Haible wrote:
Giulio Benetti wrote:
There should not be a <gettext.h> in public include file directories!

Indeed there is not, there is <libintl.h> and it is part of uclibc:

Ah! Most of the contents of this <libintl.h> is OK. But
   - gettext_noop
   - gettext_printf
don't belong there.

I see that usually glibc #define gettext_noop() in regex_internal.h that in order #include libintl.h[1] so, the same usage as gnulib does.

What I was proposing at the beginning was to add:
#undef gettext_noop

the same way uClibc does.

The compiler warning about a redefined macros is meant to catch unintentional
overriding definitions. For example, when a program defines gettext_noop
and afterwards #includes "gettext.h". It is reasonable to keep this warning
in the general case.

Yes, but we get problems when somebody passes -Werror and this can occur.

Therefore the right action is that the uClibc people remove their definition
of gettext_noop and gettext_printf from this file.

uClibc-ng embeds gettext-tiny which has that libintl.h flavour where they define gettext_noop() and gettext_printf() [2]. But their purpose is exaclty to provide a stub for gettext. So I end up with the conclusion that libbytesize has the problem, none of you all(gnulib, uClibc-ng, glibc). Basically the problem is that they define -DENABLE_NLS in any case without taking into account if the build system provide or not a gettext lib(gettext, gettext-tiny), so they enable gnulib's gettext.h by default then we get to double #define.

The only fix to do is in libbytesize/configure.ac: append -DENABLE_NLS to CFLAGS only if gettext is not found in build system.

In the meanwhile I've added the workaround I've pointed here with this patch, but this is not the solution.

Writing this e-mail everything got clear to me :-) so sorry for the noise, anyway it was also to give you an answer.


Kind regards
Giulio Benetti
Benetti Engineering sas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]