[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Romain Naour]

See gperf 3.1 ChangeLog:
* The 'len' parameter of the hash function and of the lookup function is now
  of type 'size_t' instead of 'unsigned int'. This makes it safe to call these
  functions with strings of length > 4 GB, on 64-bit machines.

Fixes:
http://autobuild.buildroot.net/results/a2d/a2da03b1a586fcfb0c7f9146aaf24bfab2e885b0

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
---
I haven't checked how many packages are affected by this breakage...
---
 ...p-Change-the-len-parameter-type-to-size_t.patch | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch

diff --git a/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch b/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch
new file mode 100644
index 0000000..e28f780
--- /dev/null
+++ b/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch
@@ -0,0 +1,43 @@
+From 532493467fa751edb12dc06b5e12c72d5d9baeef Mon Sep 17 00:00:00 2001
+From: Romain Naour <romain.naour@gmail.com>
+Date: Tue, 17 Jan 2017 22:55:53 +0100
+Subject: [PATCH] libcap: Change the 'len' parameter type to 'size_t'
+
+See gperf 3.1 ChangeLog:
+* The 'len' parameter of the hash function and of the lookup function is now
+  of type 'size_t' instead of 'unsigned int'. This makes it safe to call these
+  functions with strings of length > 4 GB, on 64-bit machines.
+
+Fixes:
+http://autobuild.buildroot.net/results/a2d/a2da03b1a586fcfb0c7f9146aaf24bfab2e885b0
+
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+---
+ libcap/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libcap/Makefile b/libcap/Makefile
+index d189777..40cbc30 100644
+--- a/libcap/Makefile
++++ b/libcap/Makefile
+@@ -22,7 +22,7 @@ all: $(MINLIBNAME) $(STALIBNAME) libcap.pc
+ 
+ ifeq ($(BUILD_GPERF),yes)
+ USE_GPERF_OUTPUT = $(GPERF_OUTPUT)
+-INCLUDE_GPERF_OUTPUT = -include $(GPERF_OUTPUT)
++INCLUDE_GPERF_OUTPUT = -include string.h -include $(GPERF_OUTPUT)
+ endif
+ 
+ libcap.pc: libcap.pc.in
+@@ -41,7 +41,7 @@ cap_names.h: _makenames
+ 	./_makenames > cap_names.h
+ 
+ $(GPERF_OUTPUT): cap_names.list.h
+-	perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($$l = <>) { $$l =~ s/[\{\"]//g; $$l =~ s/\}.*// ; print $$l; }' < $< | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20 $(INDENT) > $@
++	perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, size_t);\n%}\n%%\n"; while ($$l = <>) { $$l =~ s/[\{\"]//g; $$l =~ s/\}.*// ; print $$l; }' < $< | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20 $(INDENT) > $@
+ 
+ cap_names.list.h: Makefile $(KERNEL_HEADERS)/linux/capability.h
+ 	@echo "=> making $@ from $(KERNEL_HEADERS)/linux/capability.h"
+-- 
+2.9.3
+
-- 
2.9.3

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Alvaro Gamez]

El 17/1/2017 23:17, "Romain Naour" <romain.naour@gmail.com> escribi?:

See gperf 3.1 ChangeLog:
* The 'len' parameter of the hash function and of the lookup function is now
  of type 'size_t' instead of 'unsigned int'. This makes it safe to call
these
  functions with strings of length > 4 GB, on 64-bit machines.

[...]
I haven't checked how many packages are affected by this breakage...
---


I think there's only a handful of packages that depend on gperf. I'll try
to test them all starting this afternoon.

Sorry for the inconvenience!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170118/69dc5091/attachment.html>

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Peter Korsgaard]

>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes:

 > See gperf 3.1 ChangeLog:
 > * The 'len' parameter of the hash function and of the lookup function is now
 >   of type 'size_t' instead of 'unsigned int'. This makes it safe to call these
 >   functions with strings of length > 4 GB, on 64-bit machines.

:/

Have you submitted this patch upstream? Doesn't this then break building
against gperf <3.1?

I think I'll apply Gustavoz patch to (temporarily) revert the gperf bump
instead. Once we have sorted out this libcap issue (and apparently eudev
as well) we can bump the version again.

 > Fixes:
 > http://autobuild.buildroot.net/results/a2d/a2da03b1a586fcfb0c7f9146aaf24bfab2e885b0

 > Signed-off-by: Romain Naour <romain.naour@gmail.com>
 > Cc: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
 > ---
 > I haven't checked how many packages are affected by this breakage...
 > ---
 >  ...p-Change-the-len-parameter-type-to-size_t.patch | 43 ++++++++++++++++++++++
 >  1 file changed, 43 insertions(+)
 >  create mode 100644 package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch

 > diff --git a/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch b/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch
 > new file mode 100644
 > index 0000000..e28f780
 > --- /dev/null
 > +++ b/package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch
 > @@ -0,0 +1,43 @@
 > +From 532493467fa751edb12dc06b5e12c72d5d9baeef Mon Sep 17 00:00:00 2001
 > +From: Romain Naour <romain.naour@gmail.com>
 > +Date: Tue, 17 Jan 2017 22:55:53 +0100
 > +Subject: [PATCH] libcap: Change the 'len' parameter type to 'size_t'
 > +
 > +See gperf 3.1 ChangeLog:
 > +* The 'len' parameter of the hash function and of the lookup function is now
 > +  of type 'size_t' instead of 'unsigned int'. This makes it safe to call these
 > +  functions with strings of length > 4 GB, on 64-bit machines.
 > +
 > +Fixes:
 > +http://autobuild.buildroot.net/results/a2d/a2da03b1a586fcfb0c7f9146aaf24bfab2e885b0
 > +
 > +Signed-off-by: Romain Naour <romain.naour@gmail.com>
 > +---
 > + libcap/Makefile | 4 ++--
 > + 1 file changed, 2 insertions(+), 2 deletions(-)
 > +
 > +diff --git a/libcap/Makefile b/libcap/Makefile
 > +index d189777..40cbc30 100644
 > +--- a/libcap/Makefile
 > ++++ b/libcap/Makefile
 > +@@ -22,7 +22,7 @@ all: $(MINLIBNAME) $(STALIBNAME) libcap.pc
 > + 
 > + ifeq ($(BUILD_GPERF),yes)
 > + USE_GPERF_OUTPUT = $(GPERF_OUTPUT)
 > +-INCLUDE_GPERF_OUTPUT = -include $(GPERF_OUTPUT)
 > ++INCLUDE_GPERF_OUTPUT = -include string.h -include $(GPERF_OUTPUT)
 > + endif
 > + 
 > + libcap.pc: libcap.pc.in
 > +@@ -41,7 +41,7 @@ cap_names.h: _makenames
 > + 	./_makenames > cap_names.h
 > + 
 > + $(GPERF_OUTPUT): cap_names.list.h
 > +-	perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($$l = <>) { $$l =~ s/[\{\"]//g; $$l =~ s/\}.*// ; print $$l; }' < $< | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20 $(INDENT) > $@
 > ++	perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, size_t);\n%}\n%%\n"; while ($$l = <>) { $$l =~ s/[\{\"]//g; $$l =~ s/\}.*// ; print $$l; }' < $< | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20 $(INDENT) > $@
 > + 
 > + cap_names.list.h: Makefile $(KERNEL_HEADERS)/linux/capability.h
 > + 	@echo "=> making $@ from $(KERNEL_HEADERS)/linux/capability.h"
 > +-- 
 > +2.9.3
 > +
 > -- 
 > 2.9.3

 > _______________________________________________
 > buildroot mailing list
 > buildroot at busybox.net
 > http://lists.busybox.net/mailman/listinfo/buildroot

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Thomas Petazzoni]

Hello,

On Tue, 17 Jan 2017 23:17:23 +0100, Romain Naour wrote:
> + libcap/Makefile | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/libcap/Makefile b/libcap/Makefile
> +index d189777..40cbc30 100644
> +--- a/libcap/Makefile
> ++++ b/libcap/Makefile
> +@@ -22,7 +22,7 @@ all: $(MINLIBNAME) $(STALIBNAME) libcap.pc
> + 
> + ifeq ($(BUILD_GPERF),yes)
> + USE_GPERF_OUTPUT = $(GPERF_OUTPUT)
> +-INCLUDE_GPERF_OUTPUT = -include $(GPERF_OUTPUT)
> ++INCLUDE_GPERF_OUTPUT = -include string.h -include $(GPERF_OUTPUT)

This change wasn't described in the patch description.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Romain NAOUR]

Hi Peter,

Le 2017-01-18 11:31, Peter Korsgaard a ?crit :

>>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes:
> 
>> See gperf 3.1 ChangeLog:
>> * The 'len' parameter of the hash function and of the lookup function
> is now
>> of type 'size_t' instead of 'unsigned int'. This makes it safe to 
>> call
> these
>> functions with strings of length > 4 GB, on 64-bit machines.
> 
> :/
> 
> Have you submitted this patch upstream? Doesn't this then break 
> building
> against gperf <3.1?

Not yet. Indeed it break with gperf < 3.1 :-/
But I don't see how we can easily/properly handle the gperf version 
checking
in the libcap Makefile...

> 
> I think I'll apply Gustavoz patch to (temporarily) revert the gperf 
> bump
> instead. Once we have sorted out this libcap issue (and apparently 
> eudev
> as well) we can bump the version again.

Ok, it will give some time to Alvaro for investigation and test.

Best regards,
Romain

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Romain NAOUR]

Hi Thomas,

Le 2017-01-18 11:37, Thomas Petazzoni a ?crit :

> Hello,
> 
> On Tue, 17 Jan 2017 23:17:23 +0100, Romain Naour wrote:
> 
>> + libcap/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2
>> deletions(-) + +diff --git a/libcap/Makefile b/libcap/Makefile +index
>> d189777..40cbc30 100644 +--- a/libcap/Makefile ++++ b/libcap/Makefile
>> +@@ -22,7 +22,7 @@ all: $(MINLIBNAME) $(STALIBNAME) libcap.pc + + 
>> ifeq
>> ($(BUILD_GPERF),yes) + USE_GPERF_OUTPUT = $(GPERF_OUTPUT)
>> +-INCLUDE_GPERF_OUTPUT = -include $(GPERF_OUTPUT)
>> ++INCLUDE_GPERF_OUTPUT = -include string.h -include $(GPERF_OUTPUT)
> 
> This change wasn't described in the patch description.

Indeed, sorry.
It's for size_t definition as recommended in a comment added recently 
in the gperf code.

Best regards,
Romain



> 
> Thomas

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Alvaro G. M.]

On Tue, Jan 17, 2017 at 11:17:23PM +0100, Romain Naour wrote:
> I haven't checked how many packages are affected by this breakage...

rgrep host-gperf packages/ helps getting this useful list:

systemd webkitgtk libsvgtiny libcap x11r7/xcb-util eudev qt5 kodi

I've had the time to test only a few of these packages, I'll test the
remaining later on today as they are quite big and take a while to compile
on my machine.

* To be tested: systemd webkitgtk qt5 kodi

* Tested and needs patch: libcap, libsvgtiny, eudev

- libcap: compiles with Romain's patch

- libsvgtiny: needs patch:

diff -urN libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06.old/src/svgtiny_internal.h libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06/src/svgtiny_internal.h
--- libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06.old/src/svgtiny_internal.h	2011-03-21 23:07:10.000000000 +0100
+++ libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06/src/svgtiny_internal.h	2017-01-18 12:05:14.338053788 +0100
@@ -90,6 +90,6 @@
 /* colors.gperf */
 const struct svgtiny_named_color *
 		svgtiny_color_lookup(register const char *str,
-				register unsigned int len);
+				register size_t len);
 
 #endif


- eudev: needs patch too:

diff -urN eudev-3.2.1.orig/src/udev/udev-builtin-keyboard.c eudev-3.2.1/src/udev/udev-builtin-keyboard.c
--- eudev-3.2.1.orig/src/udev/udev-builtin-keyboard.c	2017-01-18 12:02:25.937207350 +0100
+++ eudev-3.2.1/src/udev/udev-builtin-keyboard.c	2017-01-18 12:02:42.149288589 +0100
@@ -28,7 +28,7 @@
 
 #include "udev.h"
 
-static const struct key *keyboard_lookup_key(const char *str, unsigned len);
+static const struct key *keyboard_lookup_key(const char *str, size_t len);
 #include "keyboard-keys-from-name.h"
 #include "keyboard-keys-to-name.h"
 

* Tested and doesn't need patch: x11r7/xcb-util

From xcb-util-0.3.9/{NEWS, ChangeLog}:
Do not rely anymore on gperf and m4 following removal of deprecated atoms.

I've grepped for gperf on xcb-util and the only references are those two and
it's built without issue, so I've already sent a patch to fix this obsolete
dependency.


Best regards

-- 
Alvaro G. M.

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Alvaro G. M.]

On Wed, Jan 18, 2017 at 12:22:49PM +0100, Alvaro G. M. wrote:
> On Tue, Jan 17, 2017 at 11:17:23PM +0100, Romain Naour wrote:
> > I haven't checked how many packages are affected by this breakage...
> 
> rgrep host-gperf packages/ helps getting this useful list:
> systemd webkitgtk libsvgtiny libcap x11r7/xcb-util eudev qt5 kodi

I grepped badly, the real list is, after removing false positive xcb-util:

 systemd webkitgtk libsvgtiny libcap eudev qt5webkit kodi

Tested and needs patch: libcap, libsvgtiny, eudev, systemd
To be tested: webkitgtk, qt5webkit, kodi

* systemd requires a patch, too, changing basically the same thing as those
  before. This is longer because it uses gperf several times, but I've got
  it ready if needed. I think I'll be sending only a patch or patch series
  with all needed changes.

I don't know how to test the remaining bits: webkitgtk, qt5webkit, kodi

They all require libgtk3, but I can't select it:
*** libgtk3 needs an OpenGL or an OpenGL-EGL/wayland backend ***

What other things do I need to enable libgtk3?

Thanks!


-- 
Alvaro G. M.

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Romain Naour]

Hi Alvaro,

Le 18/01/2017 ? 17:01, Alvaro G. M. a ?crit :
> On Wed, Jan 18, 2017 at 12:22:49PM +0100, Alvaro G. M. wrote:
>> On Tue, Jan 17, 2017 at 11:17:23PM +0100, Romain Naour wrote:
>>> I haven't checked how many packages are affected by this breakage...
>>
>> rgrep host-gperf packages/ helps getting this useful list:
>> systemd webkitgtk libsvgtiny libcap x11r7/xcb-util eudev qt5 kodi
> 
> I grepped badly, the real list is, after removing false positive xcb-util:
> 
>  systemd webkitgtk libsvgtiny libcap eudev qt5webkit kodi
> 
> Tested and needs patch: libcap, libsvgtiny, eudev, systemd
> To be tested: webkitgtk, qt5webkit, kodi
> 
> * systemd requires a patch, too, changing basically the same thing as those
>   before. This is longer because it uses gperf several times, but I've got
>   it ready if needed. I think I'll be sending only a patch or patch series
>   with all needed changes.
> 
> I don't know how to test the remaining bits: webkitgtk, qt5webkit, kodi
> 
> They all require libgtk3, but I can't select it:
> *** libgtk3 needs an OpenGL or an OpenGL-EGL/wayland backend ***
> 
> What other things do I need to enable libgtk3?

Thanks for your investigation!

libgtk3 needs an OpenGL provider, you can use Mesa3d as OpenGL provider on x86
with a Gallium driver.

But since we need to fix several package like eudev and systemd, I would suggest
to report this issue to gperf maintainer and see what he say.

Best regards,
Romain

> 
> Thanks!
> 
> 

[Buildroot] [PATCH] package/libcap: fix build with gperf >= 3.1

[Alvaro G. M.]

On Wed, Jan 18, 2017 at 10:31:51PM +0100, Romain Naour wrote:
> Hi Alvaro,
> 
> Le 18/01/2017 ? 17:01, Alvaro G. M. a ?crit :
> > On Wed, Jan 18, 2017 at 12:22:49PM +0100, Alvaro G. M. wrote:
> > I don't know how to test the remaining bits: webkitgtk, qt5webkit, kodi
> > 
> > They all require libgtk3, but I can't select it:
> > *** libgtk3 needs an OpenGL or an OpenGL-EGL/wayland backend ***
> > 
> > What other things do I need to enable libgtk3?
> 
> Thanks for your investigation!
> 
> libgtk3 needs an OpenGL provider, you can use Mesa3d as OpenGL provider on x86
> with a Gallium driver.

Thank you! I've been able to select them now. However, cairo compilation
fails regarding OpenGL. I guess this is a bug on buildroot's cairo package?

checking whether cairo's OpenGLESv2 surface backend feature could be enabled... no (glesv2.pc nor OpenGL ES 2.0 headers not found)
configure: error:  OpenGLESv2 surface backend feature could not be enabled
package/pkg-generic.mk:206: recipe for target '/tmp/buildroot/output/build/cairo-1.14.8/.stamp_configured' failed
make: *** [/tmp/buildroot/output/build/cairo-1.14.8/.stamp_configured] Error 1

> 
> But since we need to fix several package like eudev and systemd, I would suggest
> to report this issue to gperf maintainer and see what he say.

Yes, I agree. My intuition says most people probably won't even know that
gperf has released a new version (3.0.4 was released in 2009), so maybe
gperf maintainer will want to set a default option to let it behave as
previous version, so it remains compatible.


I'll write to gperf mailing list and see what his opinions are on the
matter.


Best regards

-- 
Alvaro G. M.