http://bugs.gentoo.org/250342

http://sources.redhat.com/bugzilla/show_bug.cgi?id=9685

we cant assume sock_cloexec and pipe2 are bound together as the former defines

are found in glibc only while the latter are a combo of kernel headers and

glibc.  so if we do a runtime detection of SOCK_CLOEXEC, but pipe2() is a stub

inside of glibc, we hit a problem.  for example:

#include <grp.h>

#include <stdio.h>

main()

{

	getgrnam("portage");

	if (!popen("ls", "r"))

		perror("popen()");

}

getgrnam() will detect that the kernel supports SOCK_CLOEXEC and then set both

__have_sock_cloexec and __have_pipe2 to true.  but if glibc was built against

older kernel headers where __NR_pipe2 does not exist, glibc will have a ENOSYS

stub for it.  so popen() will always fail as glibc assumes pipe2() works.

diff -durN glibc-2.10.1.orig/include/unistd.h glibc-2.10.1/include/unistd.h

--- glibc-2.10.1.orig/include/unistd.h	2008-07-27 20:23:17.000000000 +0200

+++ glibc-2.10.1/include/unistd.h	2009-11-13 00:50:15.000000000 +0100

@@ -167,9 +167,6 @@

 extern int __pause_nocancel (void) attribute_hidden;

 extern int __have_sock_cloexec;

-/* At lot of other functionality became available at the same time as

-   SOCK_CLOEXEC.  Avoid defining separate variables for all of them

-   unless it is really necessary.  */

-#define __have_pipe2 __have_sock_cloexec

+extern int __have_pipe2;

 #endif

diff -durN glibc-2.10.1.orig/socket/have_sock_cloexec.c glibc-2.10.1/socket/have_sock_cloexec.c

--- glibc-2.10.1.orig/socket/have_sock_cloexec.c	2008-07-25 18:46:23.000000000 +0200

+++ glibc-2.10.1/socket/have_sock_cloexec.c	2009-11-13 00:50:15.000000000 +0100

@@ -16,9 +16,14 @@

    Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA

    02111-1307 USA.  */

+#include <fcntl.h>

 #include <sys/socket.h>

 #include <kernel-features.h>

 #if defined SOCK_CLOEXEC && !defined __ASSUME_SOCK_CLOEXEC

 int __have_sock_cloexec;

 #endif

+

+#if defined O_CLOEXEC && !defined __ASSUME_PIPE2

+int __have_pipe2;

+#endif