[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
status of C++ support with GNULIB_NAMESPACE
From: |
Bruno Haible |
Subject: |
status of C++ support with GNULIB_NAMESPACE |
Date: |
Sun, 20 Nov 2016 13:23:01 +0100 |
User-agent: |
KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) |
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
- status of C++ support with GNULIB_NAMESPACE,
Bruno Haible <=