Skip to contentSkip to conversation

package/libcap: fix build with gperf >= 3.1

PATCH New Romain Naour 5 participants 10 messages Jan 17, 2017 – Jan 19, 2017

lore
Share & tools
lore

Romain Naour

author
#0 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

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 <[email protected]>
Cc Alvaro Gamez Machado <[email protected]>

---
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
package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch new file +43 -0
new file mode 100644
index 0000000..e28f780
@@ -0,0 +1,43 @@
+From 532493467fa751edb12dc06b5e12c72d5d9baeef Mon Sep 17 00:00:00 2001
+From: Romain Naour <[email protected]>
+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 <[email protected]>
+---
+ 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
+
Signature · 1 line
2.9.3
#1 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

El 17/1/2017 23:17, "Romain Naour" <[email protected]> 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>

#2 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

In reply to Romain Naour
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Romain" == Romain Naour <[email protected]> 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.

Quoted 68 lines

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

Signed-off-by Romain Naour <[email protected]>
Cc Alvaro Gamez Machado <[email protected]>

---
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
package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch new file +43 -0
new file mode 100644
index 0000000..e28f780
@@ -0,0 +1,43 @@
+From 532493467fa751edb12dc06b5e12c72d5d9baeef Mon Sep 17 00:00:00 2001
+From: Romain Naour <[email protected]>
+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 <[email protected]>
+---
+ 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
+
Signature · 6 lines
2.9.3

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 1 line
Bye, Peter Korsgaard
#3 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

Hi Peter,

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

Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Romain" == Romain Naour <[email protected]> writes:

See gperf 3.1 ChangeLog:
* The 'len' parameter of the hash function and of the lookup function

is now

Quoted 2 lines

of type 'size_t' instead of 'unsigned int'. This makes it safe to call

Quoted 8 lines

these

Quoted 1 line

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

Quoted 6 lines

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

#4 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

In reply to Romain Naour

Hello,

package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch line 28

Quoted 13 lines · Romain Naour

+ libcap/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)

package/libcap/0004-libcap-Change-the-len-parameter-type-to-size_t.patch new file +11 -0
+
+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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#5 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

Hi Thomas,

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

Quoted 13 lines

Hello,

Quoted 8 lines · Romain Naour

+ 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)

Quoted 1 line

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

Quoted 2 lines

Thomas

#6 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

In reply to Romain Naour
Quoted 1 line · Romain Naour

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:

src/svgtiny_internal.h +1 -1
diff -urN libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06.old/src/svgtiny_internal.h libsvgtiny-ea9d99fc8b231c22d06168135e181d61f4eb2f06/src/svgtiny_internal.h
@@ -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:

src/udev/udev-builtin-keyboard.c +1 -1
diff -urN eudev-3.2.1.orig/src/udev/udev-builtin-keyboard.c eudev-3.2.1/src/udev/udev-builtin-keyboard.c
@@ -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

Signature · 1 line
Alvaro G. M.
#7 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

Quoted 5 lines · Alvaro G. M.
Quoted 1 line · Romain Naour

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!

Signature · 1 line
Alvaro G. M.
author
#8 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

Hi Alvaro,

Le 18/01/2017 ? 17:01, Alvaro G. M. a ?crit :

Quoted 19 lines · Alvaro G. M.
Quoted 5 lines · Romain Naour
Quoted 1 line

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.

Quoted 6 lines

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

Quoted 4 lines

Thanks!

#9 lore raw

PATCH 1/1 package/libcap: fix build with gperf >= 3.1

Quoted 9 lines · Romain Naour

Hi Alvaro,

Le 18/01/2017 ? 17:01, Alvaro G. M. a ?crit :

Quoted 6 lines · Alvaro G. M.

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

Quoted 6 lines
Quoted 1 line

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

Quoted 3 lines

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

Signature · 1 line
Alvaro G. M.