Hi all.

The reported problem appeared with r118356 when some C99 related inline 
changes were introduced. Fixinclude hacks `glibc_c99_inline_[1234]` were 
introduced and adapted by Geoffrey and Richard respectively, to deal with 
broken headers. Later, PR29867 was filed, it seemed that more headers needed 
additional treatment. A closer look at some of the files involved in above 
mentioned hacks, especially features.h which should be fixed by 
`glibc_c99_inline_1`, gave that, this specific fix was never applied, thus 
__USE_EXTERN_INLINES became defined therefore pulling in all those headers 
that shouldn't, e.g. mathinline.h from math.h (see also PR30008). This again, 
resulted in thousands of errors (as reported).

The reason `glibc_c99_inline_1` was never applied are non-standard file 
locations. On my system (debian), e.g.:

     $> cat /usr/include/features.h
     #ifdef __x86_64__
     #include <x86_64-linux/features.h>
     #endif
     #ifdef __i386__
     #include <i486-linux/features.h>
     #endif

The same holds for Roger's gentoo system, here the path are nested even deeper 
(see attachment to PR29867). The hacks `glibc_c99_inline_[1234]` apply 
correctly if used in /usr/include/<ditro-specific-path>/<files> instead 
of /usr/include/<files> (bootstrapped and regtested r120053). Thus, the 
attached patch is straighforward and lists all known file locations - which, 
in turn, invalidates it. Any other distribution may add other paths, which 
would give the same reports again and again.

Is there any mechanism in fixincludes that allows for a file at arbitrary 
positions within /usr/include? I could not find one. Internally, fixincl.c 
uses strstr() to check whether a path matches, no help there. Applying the 
fixes to all files would presumely result in a couple of false positives as 
e.g.  `glibc_c99_inline_3` matches a few times within the tree.

Any hints how to proceed? Bruce?

Regards
        Daniel
Index: inclhack.def
===================================================================
--- inclhack.def	(revision 120053)
+++ inclhack.def	(working copy)
@@ -1295,6 +1295,10 @@
 fix = {
     hackname  = glibc_c99_inline_1;
     files     = features.h;
+    files     = i486-linux/features.h;
+    files     = x86_64-linux/features.h;
+    files     = gentoo-multilib/x86/features.h;
+    files     = gentoo-multilib/amd64/features.h;
     select    = "^ *&& !defined __OPTIMIZE_SIZE__ && !defined __NO_INLINE__$";
     c_fix     = format;
     c_fix_arg = "%0 && __STDC_VERSION__ < 199901L";
@@ -1315,6 +1319,10 @@
 fix = {
     hackname  = glibc_c99_inline_2;
     files     = sys/stat.h;
+    files     = i486-linux/sys/stat.h;
+    files     = x86_64-linux/sys/stat.h;
+    files     = gentoo-multilib/x86/sys/stat.h;
+    files     = gentoo-multilib/amd64/sys/stat.h;
     select    = "extern __inline__ int";
     sed	      = "s/extern int \\(stat\\|lstat\\|fstat\\|mknod\\)/"
 		"#if __STDC_VERSION__ < 199901L\\\nextern\\\n#endif\\\n"
@@ -1337,6 +1345,10 @@
 fix = {
     hackname  = glibc_c99_inline_3;
     files     = bits/string2.h;
+    files     = i486-linux/bits/string2.h;
+    files     = x86_64-linux/bits/string2.h;
+    files     = gentoo-multilib/x86/bits/string2.h;
+    files     = gentoo-multilib/amd64/bits/string2.h;
     bypass    = "__STDC_VERSION__";
     c_fix     = format;
     c_fix_arg = "# if defined(__cplusplus) || __STDC_VERSION__ >= 19901L";
@@ -1354,6 +1366,10 @@
 fix = {
     hackname  = glibc_c99_inline_4;
     files     = sys/sysmacros.h;
+    files     = i486-linux/sys/sysmacros.h;
+    files     = x86_64-linux/sys/sysmacros.h;
+    files     = gentoo-multilib/x86/sys/sysmacros.h;
+    files     = gentoo-multilib/amd64/sys/sysmacros.h;
     bypass    = "__STDC_VERSION__";
     c_fix     = format;
     c_fix_arg = "\n#if __STDC_VERSION__ < 19901L\nextern\n#endif\n";

Reply via email to