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

2020-01-26 Thread Bruno Haible
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?

> 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.

Bruno




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

2020-01-26 Thread Giulio Benetti

On 1/26/20 11:47 PM, Giulio Benetti wrote:

Hi Bruno,

On 1/26/20 11:12 PM, Bruno Haible wrote:

Hi Giulio,


Building on an environment where gettext is already present leads to
emitting a warning about gettext_noop() alread defined.


Where is the first definition of gettext_noop located? In another copy
of gettext.h? In a third-party .h file? Or in the .c file that is being
compiled?


In a entire gettext. In my specific case I'm adding package libbytesize


Here  I meant:
In a environment where gettext is already installed.


[1], where they add src/gettext.h but they define ENABLE_NLS in any case
[2]. Maybe configure.ac should define it or not according to gettext
presence... What do you think?

Here I've opened a pull request:
https://github.com/storaged-project/libbytesize/pull/64

The goal is to add libbytesize to Buildroot.

[1]: https://github.com/storaged-project/libbytesize
[2]:
https://github.com/storaged-project/libbytesize/blob/master/configure.ac#L21



--
Giulio Benetti
Benetti Engineering sas



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

2020-01-26 Thread Giulio Benetti

Hi Bruno,

On 1/26/20 11:12 PM, Bruno Haible wrote:

Hi Giulio,


Building on an environment where gettext is already present leads to
emitting a warning about gettext_noop() alread defined.


Where is the first definition of gettext_noop located? In another copy
of gettext.h? In a third-party .h file? Or in the .c file that is being
compiled?


In a entire gettext. In my specific case I'm adding package libbytesize 
[1], where they add src/gettext.h but they define ENABLE_NLS in any case 
[2]. Maybe configure.ac should define it or not according to gettext 
presence... What do you think?


Here I've opened a pull request:
https://github.com/storaged-project/libbytesize/pull/64

The goal is to add libbytesize to Buildroot.

[1]: https://github.com/storaged-project/libbytesize
[2]: 
https://github.com/storaged-project/libbytesize/blob/master/configure.ac#L21


--
Giulio Benetti
Benetti Engineering sas


Bruno







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

2020-01-26 Thread Bruno Haible
Hi Giulio,

> Building on an environment where gettext is already present leads to
> emitting a warning about gettext_noop() alread defined.

Where is the first definition of gettext_noop located? In another copy
of gettext.h? In a third-party .h file? Or in the .c file that is being
compiled?

Bruno




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

2020-01-26 Thread Giulio Benetti
Building on an environment where gettext is already present leads to
emitting a warning about gettext_noop() alread defined. And if -Werror
is passed this warning will be treated like an error, so let's #undef
gettext_noop() before #define it.

Signed-off-by: Giulio Benetti 
---
 lib/gettext.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/gettext.h b/lib/gettext.h
index 249668af6..641113e43 100644
--- a/lib/gettext.h
+++ b/lib/gettext.h
@@ -106,6 +106,7 @@
and other string expressions won't work.
The macro's expansion is not parenthesized, so that it is suitable as
initializer for static 'char[]' or 'const char[]' variables.  */
+#undef gettext_noop
 #define gettext_noop(String) String
 
 /* The separator between msgctxt and msgid in a .mo file.  */
-- 
2.20.1




Re: fseeko issues in mys2/mingw64

2020-01-26 Thread John Donoghue

On 1/25/20 6:11 PM, Bruno Haible wrote:

- the patch was fine.

Thanks for the feedback.

Bruno


Thanks for the quick response times and help in resolving the bug!




Re: [PATCH] regex: port to Gawk on nonstandard platforms

2020-01-26 Thread arnold
Hi. Paul.

> diff --git a/lib/regex_internal.h b/lib/regex_internal.h
> index 13e15e21e..6d436fde1 100644
> --- a/lib/regex_internal.h
> +++ b/lib/regex_internal.h
> @@ -141,6 +141,9 @@
>  #ifndef SSIZE_MAX
>  # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
>  #endif
> +#ifndef ULONG_WIDTH
> +# define ULONG_WIDTH (CHAR_BIT * sizeof (unsigned long int))
> +#endif
>  
>  /* The type of indexes into strings.  This is signed, not size_t,
> since the API requires indexes to fit in regoff_t anyway, and using

This change is problematic.  Further on in regex_internal.h we
have

#define BITSET_WORD_BITS ULONG_WIDTH

And then in places in regcomp.c BITSET_WORD_BITS is tested in
several #if/#elif statements.

Thus on systems that don't provide ULONG_WIDTH, we end up with
expressions in #if/#elif that wants to use sizeof.

Needless to say, this fails spectactularly. :-(

Can you revert to the original code or to something else that
will compile on systems where ULONG_WIDTH is not defined?

Much thanks,

Arnold