scripts/addToolsVersion: properly handle .in vs. .in.2
While most components have their version in the .in file, some
have it in the .in.2 (eg. elf2flt).
Currently, to handle this case, we indiscriminately munge both files,
but this is wrong: in the elf2flt case, if we add a binutils version,
we do not want it to be added to elf2flt, and conversely.
So, for each tool, we need to explicitly know what file to munge.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
1 http://bugs.gentoo.org/250342
2 http://sources.redhat.com/bugzilla/show_bug.cgi?id=9685
4 we cant assume sock_cloexec and pipe2 are bound together as the former defines
5 are found in glibc only while the latter are a combo of kernel headers and
6 glibc. so if we do a runtime detection of SOCK_CLOEXEC, but pipe2() is a stub
7 inside of glibc, we hit a problem. for example:
14 if (!popen("ls", "r"))
18 getgrnam() will detect that the kernel supports SOCK_CLOEXEC and then set both
19 __have_sock_cloexec and __have_pipe2 to true. but if glibc was built against
20 older kernel headers where __NR_pipe2 does not exist, glibc will have a ENOSYS
21 stub for it. so popen() will always fail as glibc assumes pipe2() works.
23 diff -durN glibc-2.12.1.orig/socket/have_sock_cloexec.c glibc-2.12.1/socket/have_sock_cloexec.c
24 --- glibc-2.12.1.orig/socket/have_sock_cloexec.c 2008-07-25 18:46:23.000000000 +0200
25 +++ glibc-2.12.1/socket/have_sock_cloexec.c 2009-11-13 00:50:15.000000000 +0100
27 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
31 #include <sys/socket.h>
32 #include <kernel-features.h>
34 #if defined SOCK_CLOEXEC && !defined __ASSUME_SOCK_CLOEXEC
35 int __have_sock_cloexec;
38 +#if defined O_CLOEXEC && !defined __ASSUME_PIPE2