Raspberry Pi - WiringPi Library Package

From: "Guillermo A. Amaral" <[email protected]>

Signed-off-by Guillermo A. Amaral <[email protected]>

---

package/wiringpi/wiringpi-CLOEXEC-undefined.patch new file +11 -0

new file mode 100644
index 0000000..ca0ed99
@@ -0,0 +1,29 @@
+From 728b2634cbf661e5303b1e8cb791b909ad4e907c Mon Sep 17 00:00:00 2001
+From: "Guillermo A. Amaral" <[email protected]>
+Date: Wed, 10 Jul 2013 22:05:12 -0700
+Subject: [PATCH] Declare O_CLOEXEC on systems with an older kernel and/or
+ glibc.
+
+Signed-off-by: Guillermo A. Amaral <[email protected]>
+---
+ wiringPi/wiringPi.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+

package/wiringpi/wiringpi-CLOEXEC-undefined.patch new file +6 -0

++#endif
++
+ // Environment Variables
+ 
+ #define	ENV_DEBUG	"WIRINGPI_DEBUG"
+-- 

Hi Guillermo,

Quoted 5 lines · Guillermo A. Amaral

From: "Guillermo A. Amaral" <[email protected]>

Signed-off-by Guillermo A. Amaral <[email protected]>

---

[...]

Quoted 18 lines

package/wiringpi/wiringpi-CLOEXEC-undefined.patch new file +11 -0

new file mode 100644
index 0000000..ca0ed99
@@ -0,0 +1,29 @@
+From 728b2634cbf661e5303b1e8cb791b909ad4e907c Mon Sep 17 00:00:00 2001
+From: "Guillermo A. Amaral" <[email protected]>
+Date: Wed, 10 Jul 2013 22:05:12 -0700
+Subject: [PATCH] Declare O_CLOEXEC on systems with an older kernel and/or
+ glibc.
+
+Signed-off-by: Guillermo A. Amaral <[email protected]>
+---
+ wiringPi/wiringPi.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+

package/wiringpi/wiringpi-CLOEXEC-undefined.patch line 21

Quoted 10 lines

package/wiringpi/wiringpi-CLOEXEC-undefined.patch new file +10 -0

+diff --git a/wiringPi/wiringPi.c b/wiringPi/wiringPi.c
+index ba61d9f..2ee23b9 100644
+--- a/wiringPi/wiringPi.c
++++ b/wiringPi/wiringPi.c
+@@ -77,6 +77,10 @@
+ #define	FALSE	(1==2)
+ #endif
+ 
++#ifndef O_CLOEXEC
++#define O_CLOEXEC 0

Are you sure? I see

#define O_CLOEXEC 02000000

in include/uapi/asm-generic/fcntl.h.

Quoted 6 lines · Baruch Siach

Quoted 5 lines · Guillermo A. Amaral

From: "Guillermo A. Amaral" <[email protected]>

Signed-off-by Guillermo A. Amaral <[email protected]>

---

Quoted 9 lines

Quoted 2 lines

++#ifndef O_CLOEXEC
++#define O_CLOEXEC 0

Are you sure? I see

#define O_CLOEXEC 02000000

in include/uapi/asm-generic/fcntl.h.

Hi baruch,

Usage of O_CLOEXEC in wiringPi was added very recently, it started failing after that. I hear it still works if you're using glibc though (I haven't tested it).

Here's the output if you remove the patch:

	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c: In function ?wiringPiSetup?:
	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c:1544:49: error: ?O_CLOEXEC? undeclared (first use in this function)
	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c:1544:49: note: each undeclared identifier is reported only once for each function it appears in
	make[2]: *** [wiringPi/CMakeFiles/wiringPi.dir/wiringPi.c.o] Error 1
	make[1]: *** [wiringPi/CMakeFiles/wiringPi.dir/all] Error 2
	make: *** [all] Error 2

Hi Guillermo,

Quoted 7 lines · Guillermo A. Amaral

Quoted 6 lines · Baruch Siach

Quoted 5 lines · Guillermo A. Amaral

From: "Guillermo A. Amaral" <[email protected]>

Signed-off-by Guillermo A. Amaral <[email protected]>

---

[...]

Quoted 16 lines

Quoted 9 lines

Quoted 2 lines

++#ifndef O_CLOEXEC
++#define O_CLOEXEC 0

Are you sure? I see

#define O_CLOEXEC 02000000

in include/uapi/asm-generic/fcntl.h.

Hi baruch,

Usage of O_CLOEXEC in wiringPi was added very recently, it started failing after that. I hear it still works if you're using glibc though (I haven't tested it).

Quoted 8 lines

Here's the output if you remove the patch:

	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c: In function ?wiringPiSetup?:
	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c:1544:49: error: ?O_CLOEXEC? undeclared (first use in this function)
	/development/test/build/wiringpi-02a3bd8d8f2ae5c873e63875a8faef5b627f9db6/wiringPi/wiringPi.c:1544:49: note: each undeclared identifier is reported only once for each function it appears in
	make[2]: *** [wiringPi/CMakeFiles/wiringPi.dir/wiringPi.c.o] Error 1
	make[1]: *** [wiringPi/CMakeFiles/wiringPi.dir/all] Error 2
	make: *** [all] Error 2

I didn't say you should remove this patch, just use the correct value. Setting O_CLOEXEC to 0 makes it effectively a no-op. Is this intended?

I searched around for alternative ways around the issue when I first encountered it, it seemed no-oping it would be most portable/safest approach.

O_CLOEXEC (Since Linux 2.6.23)
Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Additionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2).

Hello Guillermo,

Am 11.07.2013 08:38, schrieb Guillermo A. Amaral:

Quoted 2 lines

I searched around for alternative ways around the issue when I first encountered it, it seemed no-oping it would be most portable/safest approach.

The O_CLOEXEC variable was introduced in 2.6.23.

Quoted 9 lines

O_CLOEXEC (Since Linux 2.6.23)
Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Additionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2).

So if you use a kernel less then 2.6.23 it make no sense to definess then 2.6.23 it make no sense to define O_CLOEXEC to whatever you want, the kernel doesn't know this. And in the
opposite you can't defined it to some different then already defined for
O_CLOEXEC.

The function 'open' can also used without the 3rd parameter.

So I think you have to check which kernel version is used and build a patch which does something like

#ifdef KERNEL_VER < 2_6_23
if ((fd = open ("/dev/mem", O_RDWR | O_SYNC) ) < 0)
#else
if ((fd = open ("/dev/mem", O_RDWR | O_SYNC | O_CLOEXEC) ) < 0)
#endif

The guys from linux-wireless do a lot of this to get the wireless package working om dif

The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is 3.2.27. :)

So there should be no need to do the kernel check, since the package is RPi specific.

The problem here was that O_CLOEXEC was not defined with the default uclibc and older versions of glibc.

Hi Guillermo,

Quoted 2 lines · Guillermo Amaral

The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is 3.2.27. :)

If this is the case, then there is no reason to make O_CLOEXEC a no-op.

Quoted 5 lines

So there should be no need to do the kernel check, since the package is RPi specific.

The problem here was that O_CLOEXEC was not defined with the default uclibc and older versions of glibc.

The O_CLOEXEC define comes with the kernel headers used to build the toolchain, not from the C library.

Quoted 12 lines · Baruch Siach

Quoted 2 lines · Guillermo Amaral

The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is 3.2.27. :)

If this is the case, then there is no reason to make O_CLOEXEC a no-op.

Quoted 5 lines

So there should be no need to do the kernel check, since the package is RPi specific.

The problem here was that O_CLOEXEC was not defined with the default uclibc and older versions of glibc.

Quoted 2 lines

The O_CLOEXEC define comes with the kernel headers used to build the toolchain, not from the C library.

I didn't say it didn't. I'll clarify, if __USE_GNU and/or __USE_XOPEN2K8 don't get defined at some point O_CLOEXEC is not getting defined. My guess is that they get defined by *libc, feel free to correct me if I'm wrong.

Hi Guillermo,

Quoted 13 lines · Guillermo Amaral

Quoted 12 lines · Baruch Siach

Quoted 2 lines · Guillermo Amaral

The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is 3.2.27. :)

If this is the case, then there is no reason to make O_CLOEXEC a no-op.

Quoted 5 lines

So there should be no need to do the kernel check, since the package is RPi specific.

The problem here was that O_CLOEXEC was not defined with the default uclibc and older versions of glibc.

Quoted 6 lines

Quoted 2 lines

The O_CLOEXEC define comes with the kernel headers used to build the toolchain, not from the C library.

I didn't say it didn't. I'll clarify, if __USE_GNU and/or __USE_XOPEN2K8 don't get defined at some point O_CLOEXEC is not getting defined. My guess is that they get defined by *libc, feel free to correct me if I'm wrong.

The code below builds just fine on my machine:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

void func(void) { open("f", O_RDWR | O_CLOEXEC); }

Quoted 21 lines · Baruch Siach

Quoted 13 lines · Guillermo Amaral

Quoted 12 lines · Baruch Siach

Quoted 2 lines · Guillermo Amaral

The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is 3.2.27. :)

If this is the case, then there is no reason to make O_CLOEXEC a no-op.

Quoted 5 lines

So there should be no need to do the kernel check, since the package is RPi specific.

The problem here was that O_CLOEXEC was not defined with the default uclibc and older versions of glibc.

Quoted 6 lines

Quoted 2 lines

The O_CLOEXEC define comes with the kernel headers used to build the toolchain, not from the C library.

I didn't say it didn't. I'll clarify, if __USE_GNU and/or __USE_XOPEN2K8 don't get defined at some point O_CLOEXEC is not getting defined. My guess is that they get defined by *libc, feel free to correct me if I'm wrong.

Quoted 7 lines

The code below builds just fine on my machine:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

void func(void) { open("f", O_RDWR | O_CLOEXEC); }

Congratulations, I'm very proud. Have a beer on me! (B)

G

P.S.

$ host/usr/bin/arm-linux-gcc -c x.c
x.c: In function ?func?:
x.c:5:38: error: ?O_CLOEXEC? undeclared (first use in this function)
x.c:5:38: note: each undeclared identifier is reported only once for each
function it appears in

$ cat x.c
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

void func(void) { open("f", O_RDWR | O_CLOEXEC); }