Discussion:
status of C++ support with GNULIB_NAMESPACE
(too old to reply)
Bruno Haible
2016-11-20 12:23:01 UTC
Permalink
Raw Message
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
Pedro Alves
2016-11-21 23:35:12 UTC
Permalink
Raw Message
Post by Bruno Haible
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
Eh, one hour!
...
Post by Bruno Haible
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.
That's what GDB already does, actually.

GDB imports gnulib in a way that makes it a separate static library, configured
separately from the programs that use it (gdb and gdbserver). This long email
explains gdb's current gnulib import setup:

https://sourceware.org/ml/gdb-patches/2012-04/msg00426.html

The code is here:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=tree;f=gdb/gnulib;h=754400e0fb14458e4e95a4f9c7c5e18930201d4a;hb=HEAD

At some early point of GDB's C++ conversion work, I pondered building
gnulib with a C++ compiler, but ended up dismissing it as both
impractical, and unnecessary.

BTW, do we know which programs use GNULIB_NAMESPACE?
I believe the initial support was done for GNU Octave, but I see
that quite recently Octave switched away from it, maybe because of
the problems with newer GCCs (I believe fixed now).

Thanks,
Pedro Alves
Mike Miller
2016-11-21 23:47:08 UTC
Permalink
Raw Message
Post by Pedro Alves
BTW, do we know which programs use GNULIB_NAMESPACE?
I believe the initial support was done for GNU Octave, but I see
that quite recently Octave switched away from it, maybe because of
the problems with newer GCCs (I believe fixed now).
Correct, we found the situation with GCC 6 at odds with how we expected
gnulib to work, and did not think it worth our time to try to fix it. We
now build an internal library of wrapper functions around gnulib using
the C compiler.

AFAICT, no other projects are using GNULIB_NAMESPACE in the wild:

https://codesearch.debian.net/search?q=%23+*define+*GNULIB_NAMESPACE
--
mike
Loading...