Am 13.06.2016 um 22:26 schrieb Guillaume Munch <g...@lyx.org>: > > Le 13/06/2016 20:50, Pavel Sanda a écrit : >> Guillaume Munch wrote: >>> Then if we are dropping g++ 4.6, does anyone know whether it makes >>> sense >> >> Sorry I might got lost somewhere in the threads around. What reasons >> do we have for dropping gcc 4.6? >> > > Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails > (it seems) at a feature as elementary as generating a default move > constructor, even when told so explicitly (which we cannot really blame > it for, given that it does not claim C++11 compliance in the first > place). Moreover, the only distribution release that is currently stuck > with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer > be around by the time 2.3 ships (unless a miracle happens), and which > offers another compiler more respectful of C++11. On the other hand, > what reasons do we have for supporting g++ 4.6?
This is CentOS 6.8: $ cc -v Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-redhat-linux Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread-Modell: posix gcc-Version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) IMO it’s not dead and end of life is 2020-11-30 Stephan > > If you really need a temporary workaround until you get to migrate your > work environment, (and you do not want to/can use clang,) you could keep > a local series of fixes. I imagine that for your current sort of problem > (as far as I understand, because I do not have access to g++ 4.6 to test > my theory), you just need manual definitions of move constructors and > assignment operators. For e87febd0 in particular, however, it is easier, > because it should be safe to just revert it locally, given that this is > an isolated change. > > > Guillaume >
