bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status of C++ support with GNULIB_NAMESPACE


From: Pedro Alves
Subject: Re: status of C++ support with GNULIB_NAMESPACE
Date: Mon, 21 Nov 2016 23:35:12 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

 On 11/20/2016 12:23 PM, Bruno Haible wrote:

> 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!

> 
> Here are the findings:

...

>   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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]