Hi Sam, > > You probably renamed the inclusion guard (_GL_STDLIB_H) > > appropriate (as recommended). > > does this "as recommended" mean that you are now more amenable to > accepting my patch? > http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log
The fact that you have been testing this approach for a year and have reported just this one problem with it gives it some trust. Also Bruce Korb's libposix needs a similar treatment. But I'm wondering whether we might see different behaviours when using compilers which support #include_next and other compilers which don't. When you have two gnulib-generated files main/gllib/stdlib.h extra/gllib/stdlib.h and the compiler options include "-Iextra/gllib -Imain/gllib", then with compilers of the first kind the program will include extra/gllib/stdlib.h -> main/gllib/stdlib.h -> /usr/include/stdlib.h whereas with compilers of the second kind the program will include extra/gllib/stdlib.h -> /usr/include/stdlib.h Such differences would be very hard to diagnose when they lead to problems. Any ideas? Bruno
