In old VxWorks headers (5.5), ioLib.h includes unistd.h via
#include "unistd.h"
We copy ioLib to include-fixed, with a few fixes applied. We also wrap
unistd.h, so that fixed header contains
#include_next <unistd.h>
This means that when user-code does
#include <ioLib.h>
they'll get the fixed header (as they should), and the include of
unistd.h from that picks up the fixed header (as it
should). Unfortunately, since "..." was used, it seems that "the
directory in the search path after the one where the current file was
found" for the include_next then ends up picking the include-fixed
directory again, so the fixed unistd.h just includes itself, and not the
system unistd.h - and at the time of the self-include, the guard macro
is defined, so we do not end up evaluating the include_next again.
Changing to an angle-include instead still makes ioLib.h pick up the
fixed unistd.h, but since we now actually use the search path,
include_next works as intended. [In at least VxWorks 6.3, ioLib.h does
use <...> to include unistd.h, so this issue doesn't exist there.]
There are lots of quote-includes like this in the VxWorks headers, and
I'm slightly surprised I can't find other examples of this kind of issue
in inclhack.def. In fact, I'd expect any #include "foo.h" in a fixed
header where foo.h is also fixed and has an #include_next <foo.h> would
have to be changed to #include <foo.h>. In fact, ioLib.h itself at
firsts seems to have the same problem with limits.h, since it also
contains
#include "limits.h"
However, in that case, the include-fixed version of limits.h does
#include "syslimits.h"
with an comment about explicitly using "..." so that we pick up
syslimits.h in the same directory, and _that_ file then does
#include_next <limits.h>
which again at first hits the include-fixed version, but this time
around we end up in the not _GCC_LIMITS_H_ branch, with
_GCC_NEXT_LIMITS_H defined, so we hit another
#include_next <limits.h>
and that time around limits.h was found via the include path, so we
finally end up recursing to the system limits.h. So this round-about
does seem to work for limits.h, but I'm wondering why that header file
alone gets special treatment by the gcc build system.
Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk>
---
fixincludes/inclhack.def | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index d8bb17fe1a1..42c60e0c13b 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4843,6 +4843,22 @@ fix = {
test_text = "extern int write ( int , char * , size_t ) ;";
};
+/*
+ * This hack ensures the include_next in the fixed unistd.h actually
+ * finds the system's unistd.h and not the fixed unistd.h again.
+ */
+fix = {
+ hackname = vxworks_iolib_include_unistd;
+ files = ioLib.h;
+ mach = "*-*-vxworks*";
+ select = "#include \"unistd.h\"";
+
+ c_fix = format;
+ c_fix_arg = "#include <unistd.h>";
+
+ test_text = "#include \"unistd.h\"";
+};
+
/*
* There are several name conflicts with C++ reserved words in X11 header
* files. These are fixed in some versions, so don't do the fixes if
--
2.15.1
