bug-gnulib
[Top][All Lists]
Advanced

[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, 27 Jan 2020 17:00:45 +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 2:41 AM, Bruno Haible wrote:
Giulio Benetti wrote:
In my specific case I'm adding package libbytesize
[1], where they add src/gettext.h

But libbytesize uses gettext.h as they should: They use the file internally,
without installing it in public locations upon "make install".

Since you reported a redefinition warning regarding 'gettext_noop',
gettext_noop must have been defined as a macro already elsewhere. Where?

gettext_noop() is defined in environment gettext.h and in libbytesize/configure.ac they define:
CFLAGS="${CFLAGS} -DENABLE_NLS"
without taking into account if we already are in an environment where gettext is already installed. So I think that this is problem, libbytesize should define ENABLE_NLS according to host gettext presence otherwise host gettext could be indirectly included(like in my case) and expose gettext_noop() and when local "gettext.h" is included and ENABLE_NLS is defined(because there are no checks on environment) gettext_noop() will be defined twice.


but they define ENABLE_NLS in any case

Defining ENABLE_NLS several times to the same value 1 is a no-brainer.
It does not produce GCC warnings.

Here I meant that in libbytesize they define ENABLE_NLS in configure.c without guarding for host gettext presence. So if you define ENABLE_NLS only once, it's enough to see gettext_noop() redefined, since it's defined in host.

Anyway gnulib is correct, the problem to be fixed is in libbytesize and it's not fixed by the PR I've already open, I need to modify configure.ac to emit ENABLE_NLS according to host gettext presence.

Sorry for the noise

Best and kind regards
--
Giulio Benetti
Benetti Engineering sas

Bruno





reply via email to

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