Bug#777778: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5
On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: 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. no, this is definitely *not* an option. cwidget and aptitude b-d on libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 nor g++-4.8 in the archive once we finish this transition. Maintainers don't have the choice to fall-back to an older version this time. Matthias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777778: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5
2015-07-20 15:24 GMT+01:00 Matthias Klose d...@debian.org: On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: 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. no, this is definitely *not* an option. cwidget and aptitude b-d on libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 nor g++-4.8 in the archive once we finish this transition. Maintainers don't have the choice to fall-back to an older version this time. Right. So I have been working through the weekend to get aptitude to compile with -std=c++11 (working in my system but still not pushed). As you reported, there are problems compiling aptitude with gcc-5 in the default mode, and after the failure that you reported it will stumble upon the same problem that cwidget when including that cwidget header (for which passing -std=c++11 is the simplest solution, and also the only that I found so far). In terms of C++-based dependencies, aptitude depends on libsigc++-2.0, xapian-core (#791312, it will not be ready immediately but soon enough, it seems), apt and boost (gcc-5 ready, it seems). I don't know the details about sigc++ and apt, but if all of them are going to be compiled with gcc-5 soon after its move to unstable, cwidget and aptitude will be ready as well. Now we have to work out the details about how to upload the changes, enable them in lockstep and avoid breakages as much as possible (e.g. tighten versions on the compiler and lib dependencies). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777778: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5
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 d...@debian.org: Package: src:cwidget Version: 0.5.17-2 Severity: normal Tags: sid stretch patch User: debian-...@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_stringcwidget::wchtype::anonymous': /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class std::__cxx11::basic_stringcwidget::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_stringcwidget::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_stringcwidget::wchtype::anonymous': /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class std::__cxx11::basic_stringcwidget::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_stringcwidget::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_stringcwidget::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
