[Aptitude-devel] Bug#777778: Bug#792681: cwidget ftbfs with GCC 5

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Sat Jul 18 21:29:25 UTC 2015


2015-07-18 09:50 Matthias Klose:
>On 07/17/2015 06:57 PM, Manuel A. Fernandez Montecelo wrote:
>> Hello,
>>
>> 2015-07-17 14:13 GMT+01:00 Matthias Klose <doko at debian.org>:
>>> Package: src:cwidget
>>> Version: 0.5.17-2
>>> Severity: normal
>>> Tags: sid stretch patch
>>> User: debian-gcc at lists.debian.org
>>> Usertags: ftbfs-gcc-5
>>>
>>> GCC 5 complains about using c++11 features without passing -std=c++11. Also
>>> setting the maintainer flag without exporting it doesn't help.
>>>
>>> patch at
>>> https://launchpadlibrarian.net/211899860/cwidget_0.5.17-2ubuntu1_0.5.17-2ubuntu2.diff.gz
>>
>> If I found the correct build log where you determined this [1], the
>> compiler fails when including
>>
>> In file included from /usr/include/c++/5/string:52:0,
>>                  from ../../../src/cwidget/curses++.h:25,
>>                  from colors.cc:22:
>>
>> Line 22 of colors is:
>> #include <cwidget/curses++.h>
>>
>> And line 25 of curses++.h is:
>> #include <string>
>>
>> The error is:
>> -----------------------
>> /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union
>> std::__cxx11::basic_string<cwidget::wchtype>::<anonymous>':
>> /usr/include/c++/5/bits/basic_string.h:119:7:   required from 'class
>> std::__cxx11::basic_string<cwidget::wchtype>'
>> ../../../src/cwidget/curses++.h:199:31:   required from here
>> /usr/include/c++/5/bits/basic_string.h:121:53: error: member
>> 'cwidget::wchtype
>> std::__cxx11::basic_string<cwidget::wchtype>::<anonymous
>> union>::_M_local_buf [1]' with constructor not allowed in union
>>   _CharT           _M_local_buf[_S_local_capacity + 1];
>>                                                      ^
>> /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted
>> unions only available with -std=c++11 or -std=gnu++11
>> -----------------------
>>
>> This is because wchtype does not seem to be able to be used as part of
>> unions inside basic_string.h because the constructors/destructors are
>> not "trivial" enough.
>>
>> I was trying to work around this for a while, because I think that
>> forcing c++11 mode will have cascading effects on rev-deps (currently
>> only one within Debian, but it is aptitude with almost 100% of
>> reported installations by popcon), but I could not find a satisfactory
>> solution yet.
>>
>> Is there a deadline to fix this?
>
>yes, Jul 31. please see my email to d-d-a.

OK.  I knew of the deadline to set GCC-5 as default, I was asking in the case
that you planned to NMU before that or not even after it was made default.


>> [1] https://people.debian.org/~doko/logs/gcc5-20150701-ftbfs/logs-failed-gcc5/cwidget_0.5.17-2_unstable_gcc5.log
>
>this was the error I saw:
>[...]
>Making all in config
>make[5]: Entering directory
>'/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config'
>/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++
>-DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../..  -Wall -Werror
>-I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2  -g -O2
>-fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT
>-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include  -c -o
>colors.lo colors.cc
>libtool: compile:  g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I.
>-I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src
>-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
>-Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0
>-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c colors.cc  -fPIC -DPIC -o
>.libs/colors.o
>In file included from /usr/include/c++/5/string:52:0,
>                 from ../../../src/cwidget/curses++.h:25,
>                 from colors.cc:22:
>/usr/include/c++/5/bits/basic_string.h: In instantiation of 'union
>std::__cxx11::basic_string<cwidget::wchtype>::<anonymous>':
>/usr/include/c++/5/bits/basic_string.h:119:7:   required from 'class
>std::__cxx11::basic_string<cwidget::wchtype>'
>../../../src/cwidget/curses++.h:199:31:   required from here
>/usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype
>std::__cxx11::basic_string<cwidget::wchtype>::<anonymous union>::_M_local_buf
>[1]' with constructor not allowed in union
>  _CharT           _M_local_buf[_S_local_capacity + 1];
>                                                     ^
>/usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only
>available with -std=c++11 or -std=gnu++11
>Makefile:448: recipe for target 'colors.lo' failed
>make[5]: *** [colors.lo] Error 1
>make[5]: Leaving directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config'
>Makefile:603: recipe for target 'all-recursive' failed
>make[4]: *** [all-recursive] Error 1

I get this error with GCC-5 even if I let the default or explicitly set
-std=c++98, which is strange -- why does it try to include C++11 stuff even
then, like the namespaces in "required from 'class
std::__cxx11::basic_string<cwidget::wchtype>'" in the errors above?  It's a bit
odd.

Also, this code did not change for many years and it was compiling fine, I was
trying to look at GCC changelog but I did not see anything immediately obvious
that it causes it to fail after years working fine.

Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as
cwidget, because it fails to compile the cwidget header, if nothing else.  But
if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for
other reasons (that I am working to fix), so we are between a rock and a hard
place.

Even if I can fix things in time before the deadline, maybe subtle changes like
the ABI problems make aptitude fail in catastrophic ways, there is not much time
to expose it and be tested before the deadline in experimental or similar.

I am thinking that the best solution is to force them to stay with gcc-4.9 for
the time being, it looks the safest bet.  After that or in parallel, as soon as
I get things working, I can upload to experimental the changes that allow them
to work with C++11, and keep it there for a while before moving to unstable.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>



More information about the Aptitude-devel mailing list