Hi,
To see where we are on C++ GNULIB_NAMESPACE support, I ran
$ ./gnulib-tool --create-testdir --with-c++-tests --with-tests
--dir=/tmp/testdir
(takes one hour, be patient) and built it on a glibc system with
$ ./configure CPPFLAGS="-DGNULIB_NAMESPACE=gggg -Wall" CC=g++
$ make -k
Here are the findings:
* GNULIB_STRICT_CHECKING and GNULIB_NAMESPACE don't work together
(errors for many functions). So, I removed the -DGNULIB_STRICT_CHECKING=1
flag for this test.
A possible fix would be to add a configure option --disable-strict-checking
in the configure scripts of the testdirs.
* memrchr
./string.h:542:1: error: new declaration 'void* memrchr(const void*, int,
size_t)'
/usr/include/string.h:117:28: error: ambiguates old declaration 'const void*
memrchr(const void*, int, size_t)'
* savewd.h
- use of INITIAL_STATE, ERROR_STATE, etc. without savewd:: qualifier
(savewd.h:81, savewd.h:126).
A possible fix would be to move the 'enum' definition out of 'struct savewd';
this would be a no-op for C but not for C++.
* Many errors due to the fact that the .c files are meant to be compiled by a
C compiler, not a C++ compiler, such that
- 1065x "initializer-string for array of chars is too long"
- 217x "invalid conversion from 'void*' to" some other pointer type
- 59x "invalid conversion from 'const void*' to" some other pointer type
- 53x other "invalid conversion from ... to ..."
- 16x "declaration of ... has a different exception specifier"
(due to 'throw ()')
- use of identifier 'class' (dfa.c)
- use of identifier 'new' (hash.c, glob.c)
- use of gnulib functions without GNULIB_NAMESPACE:: qualifier (signbit,
isfinite, globfree)
- "new declaration ..." "ambiguates old declaration ..." (strcasestr,
strerror_r, strstr)
All these errors are in the category "Not a bug", IMO, because gdb and other
packages can arrange to build the imported gnulib-lib/ directory using a
C compiler rather than a C++ compiler.
Bruno
