[RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
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 This means that when user-code does #include 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 would have to be changed to #include . 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 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 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 --- 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 "; + +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
Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
Hi, for make check-fixincludes I'm seeing: ... cmp: EOF on /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h *** ioLib.h 2018-06-20 14:14:40.035956737 +0200 --- /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h 2018-06-20 14:14:28.183925247 +0200 *** *** 17,24 #if defined( VXWORKS_WRITE_CONST_CHECK ) extern int write (int, const char*, size_t); #endif /* VXWORKS_WRITE_CONST_CHECK */ - - - #if defined( VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK ) - #include "unistd.h" - #endif /* VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK */ --- 17,19 There were fixinclude test FAILURES Makefile:176: recipe for target 'check' failed make: *** [check] Error 1 ... Thanks, - Tom
Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
On 06/20/2018 02:19 PM, Tom de Vries wrote: > Hi, > > for make check-fixincludes I'm seeing: > ... > cmp: EOF on > /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h > *** ioLib.h 2018-06-20 14:14:40.035956737 +0200 > --- /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h > 2018-06-20 14:14:28.183925247 +0200 > *** > *** 17,24 > #if defined( VXWORKS_WRITE_CONST_CHECK ) > extern int write (int, const char*, size_t); > #endif /* VXWORKS_WRITE_CONST_CHECK */ > - > - > - #if defined( VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK ) > - #include "unistd.h" > - #endif /* VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK */ > --- 17,19 > > There were fixinclude test FAILURES > Makefile:176: recipe for target 'check' failed > make: *** [check] Error 1 > ... > > Thanks, > - Tom > I can confirm that. Martin
Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
On 2018-06-20 14:35, Martin Liška wrote: > On 06/20/2018 02:19 PM, Tom de Vries wrote: >> Hi, >> >> for make check-fixincludes I'm seeing: >> ... >> cmp: EOF on >> /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h >> *** ioLib.h 2018-06-20 14:14:40.035956737 +0200 >> --- /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h >> 2018-06-20 14:14:28.183925247 +0200 >> *** >> *** 17,24 >> #if defined( VXWORKS_WRITE_CONST_CHECK ) >> extern int write (int, const char*, size_t); >> #endif /* VXWORKS_WRITE_CONST_CHECK */ >> - >> - >> - #if defined( VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK ) >> - #include "unistd.h" >> - #endif /* VXWORKS_IOLIB_INCLUDE_UNISTD_CHECK */ >> --- 17,19 >> >> There were fixinclude test FAILURES >> Makefile:176: recipe for target 'check' failed >> make: *** [check] Error 1 >> ... >> >> Thanks, >> - Tom >> > > I can confirm that. Sorry about that. I completely missed that part of the README. I also get the test failure now that I do the make check. BUT: The hunk I'm seeing has , not "unistd.h", which is also what I'd expect, since that's how it should look after fixing. Ah, it seems that fixincl.x was not regenerated when the inclhack.def patch was applied, which is probably my fault as well, since I hadn't included a proper changelog fragment. Fortunately it seems that the fix is simply to add that hunk (with the angle brackets) to tests/base/ioLib.h, now that fixincl.x has been regenerated due to a later patch. Again, sorry about all this (and for not responding sooner, but have been on vacation). Rasmus
Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
Ick. Looks like the right fix to me and it is clearly constrained to vxworks platforms. Approved by me. On Fri, May 25, 2018 at 1:58 AM, Rasmus Villemoes wrote: > 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 > > This means that when user-code does > > #include > > 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 would > have to be changed to #include . 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 > > 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 > > 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 > --- > 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 "; > + > +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 >
Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion
On 05/25/2018 08:47 AM, Bruce Korb wrote: > Ick. Looks like the right fix to me and it is clearly constrained to > vxworks platforms. Approved by me. Thanks. Installed on the trunk. jeff