> But gnulib's *overrides* the system's definition. And it > is visible after any of these header files has been included: > > lib/dynarray.h > lib/glob.in.h > lib/scratch_buffer.h > > After one of these files has been included, the application can > include any system include file, and these system include files will > typically rely on the system's definition of __* macros from . > > It's a different thing to include for the compilation of > a Gnulib .c file than to expose it through a .h file that the application > can include. In the first case, the Gnulib .c file includes a small set > of system's .h files, and therefore we can hope to have resolved the > possible conflicts in a reasonable amount of time. In the second case, > there is an uncountable number of conflicts; so, this problem will > haunt us for years if we don't fix it. > > My fix here is to process the glob-libc.h file so that it does not > rely on __* macros (that belong to the system's namespace) And likewise for dynarray.h and scratch_buffer.h. 2021-06-06 Bruno Haible scratch_buffer: Avoid conflict with prepr. macros owned by the system. * lib/scratch_buffer.h: Don't include . Define _GL_LIKELY, _GL_UNLIKELY. Include malloc/scratch_buffer.gl.h instead of malloc/scratch_buffer.h. * modules/scratch_buffer (Depends-on): Add builtin-expect. (Makefile.am): Arrange to create malloc/scratch_buffer.gl.h from malloc/scratch_buffer.h. 2021-06-06 Bruno Haible dynarray: Avoid conflict with preprocessor macros owned by the system. * lib/dynarray.h: Don't include . Define _GL_LIKELY, _GL_UNLIKELY. Include malloc/dynarray.gl.h instead of malloc/dynarray.h. Include malloc/dynarray-skeleton.gl.h instead of malloc/dynarray-skeleton.c. * modules/dynarray (Depends-on): Add builtin-expect. (Makefile.am): Arrange to create malloc/dynarray.gl.h from malloc/dynarray.h and malloc/dynarray-skeleton.gl.h from malloc/dynarray-skeleton.c.