crosstool-ng/packages/glibc/2.16.0/260-assume-pipe2.patch
Alexey Neyman f8d4ce3d0e Implement a script for checking packages
Then use this script to check that all packages can be extracted and patched.

Signed-off-by: Alexey Neyman <stilor@att.net>
2017-08-23 16:05:40 -07:00

41 lines
1.4 KiB
Diff

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.16.0.orig/socket/have_sock_cloexec.c glibc-2.16.0/socket/have_sock_cloexec.c
--- glibc-2.16.0.orig/socket/have_sock_cloexec.c 2008-07-25 18:46:23.000000000 +0200
+++ glibc-2.16.0/socket/have_sock_cloexec.c 2009-11-13 00:50:15.000000000 +0100
@@ -15,9 +15,14 @@
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
+#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