Hi Darshit,
> I've attached a simple patch that fixes the build on my end. This simply
> assumes the latest version of Gperf is used to generate the files.
Thanks. I've applied your patch (with an added space between
'#include' and the file name - to follow common coding conventions).
If you
I've attached a simple patch that fixes the build on my end. This simply
assumes the latest version of Gperf is used to generate the files.
* Paul Eggert [170213 17:15]:
On 02/13/2017 07:24 AM, Darshit Shah wrote:
simply changing the prototype will cause builds to fail
On 02/13/2017 09:50 AM, Paul Eggert wrote:
> On 02/13/2017 07:24 AM, Darshit Shah wrote:
>> simply changing the prototype will cause builds to fail with older
>> versions of gperf.
>
> Simplest would be to change it to size_t, as we can assume developers
> using gnulib have recent developer
On 02/12/2017 02:47 AM, Sami Kerola wrote:
>
> Using --prefix '' works fine when runnign from command line, but I could not
> make empty string and AC_INIT to play together without the macro starting
> to throw warnings. Here is how that turns out:
>
> $ head -1 configure.ac
>
Sure, if making such a change is okay, I can prepare the patch quickly.
I will also go through all the other gperf files in the repository and
update their respective prototypes as well.
* Paul Eggert [170213 17:15]:
On 02/13/2017 07:24 AM, Darshit Shah wrote:
simply
On 02/13/2017 07:24 AM, Darshit Shah wrote:
simply changing the prototype will cause builds to fail with older
versions of gperf.
Simplest would be to change it to size_t, as we can assume developers
using gnulib have recent developer tools. Could you prepare a patch
along those lines?
Gperf 3.1 was recently released and it changes the `len` parameter of
the hash function to type `size_t` instead of the old `unsigned int`.
This breaks the unicase module which defines the prototype of the hash
function as:
gl_unicase_special_lookup (const char *str, unsigned int len);