Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
On 19 December 2011 14:55, Konstantinos Margaritis mar...@genesi-usa.com wrote: On 19 December 2011 01:55, Matthias Klose d...@debian.org wrote: Please have a look at the gcc-4.7 package in experimental, update patches (hurd, kfreebsd, ARM is fixed in svn), and investigate the build failures (currently ia64, but more will appear). Attached is the build failure on armhf (clean chroot with all bdeps satisfied). Just tested 4.7-20111222-1 as well, it built fine, installed and tested 5 known gcc ICEs (ace, webkit, 2 neon-related ones, a gfortran one) and all but one neon ICE were fixed :) Regards Konstantinos -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabsevwt_qdasf6hg_ev2e3vvexdnnrxdvsqjerfbz6rbae4...@mail.gmail.com
Processing of gcc-4.7_4.7-20111231-1_amd64.changes
gcc-4.7_4.7-20111231-1_amd64.changes uploaded successfully to localhost along with the files: gcc-4.7_4.7-20111231-1.dsc gcc-4.7_4.7-20111231.orig.tar.gz gcc-4.7_4.7-20111231-1.diff.gz gcc-4.7-source_4.7-20111231-1_all.deb cpp-4.7-doc_4.7-20111231-1_all.deb libstdc++6-4.7-doc_4.7-20111231-1_all.deb gfortran-4.7-doc_4.7-20111231-1_all.deb gcc-4.7-doc_4.7-20111231-1_all.deb gcc-4.7-locales_4.7-20111231-1_all.deb gcc-4.7-base_4.7-20111231-1_amd64.deb libgcc1_4.7-20111231-1_amd64.deb libgcc1-dbg_4.7-20111231-1_amd64.deb lib32gcc1_4.7-20111231-1_amd64.deb lib32gcc1-dbg_4.7-20111231-1_amd64.deb libquadmath0_4.7-20111231-1_amd64.deb libquadmath0-dbg_4.7-20111231-1_amd64.deb lib32quadmath0_4.7-20111231-1_amd64.deb lib32quadmath0-dbg_4.7-20111231-1_amd64.deb libgomp1_4.7-20111231-1_amd64.deb libgomp1-dbg_4.7-20111231-1_amd64.deb lib32gomp1_4.7-20111231-1_amd64.deb lib32gomp1-dbg_4.7-20111231-1_amd64.deb libitm1_4.7-20111231-1_amd64.deb libitm1-dbg_4.7-20111231-1_amd64.deb lib32itm1_4.7-20111231-1_amd64.deb lib32itm1-dbg_4.7-20111231-1_amd64.deb cpp-4.7_4.7-20111231-1_amd64.deb fixincludes_4.7-20111231-1_amd64.deb libmudflap0-4.7-dev_4.7-20111231-1_amd64.deb libmudflap0_4.7-20111231-1_amd64.deb libmudflap0-dbg_4.7-20111231-1_amd64.deb lib32mudflap0_4.7-20111231-1_amd64.deb lib32mudflap0-dbg_4.7-20111231-1_amd64.deb gobjc++-4.7-multilib_4.7-20111231-1_amd64.deb gobjc++-4.7_4.7-20111231-1_amd64.deb gobjc-4.7-multilib_4.7-20111231-1_amd64.deb gobjc-4.7_4.7-20111231-1_amd64.deb libobjc4_4.7-20111231-1_amd64.deb libobjc4-dbg_4.7-20111231-1_amd64.deb lib32objc4_4.7-20111231-1_amd64.deb lib32objc4-dbg_4.7-20111231-1_amd64.deb libgo0_4.7-20111231-1_amd64.deb libgo0-dbg_4.7-20111231-1_amd64.deb lib32go0_4.7-20111231-1_amd64.deb lib32go0-dbg_4.7-20111231-1_amd64.deb gccgo-4.7_4.7-20111231-1_amd64.deb gccgo-4.7-multilib_4.7-20111231-1_amd64.deb g++-4.7-multilib_4.7-20111231-1_amd64.deb g++-4.7_4.7-20111231-1_amd64.deb libstdc++6_4.7-20111231-1_amd64.deb lib32stdc++6_4.7-20111231-1_amd64.deb lib32stdc++6-4.7-dbg_4.7-20111231-1_amd64.deb libstdc++6-4.7-dev_4.7-20111231-1_amd64.deb libstdc++6-4.7-pic_4.7-20111231-1_amd64.deb libstdc++6-4.7-dbg_4.7-20111231-1_amd64.deb libgfortran3_4.7-20111231-1_amd64.deb libgfortran3-dbg_4.7-20111231-1_amd64.deb lib32gfortran3_4.7-20111231-1_amd64.deb lib32gfortran3-dbg_4.7-20111231-1_amd64.deb gfortran-4.7-multilib_4.7-20111231-1_amd64.deb gfortran-4.7_4.7-20111231-1_amd64.deb gcc-4.7-multilib_4.7-20111231-1_amd64.deb gcc-4.7-plugin-dev_4.7-20111231-1_amd64.deb gcc-4.7_4.7-20111231-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rh0rh-0003lq...@franck.debian.org
gcc-4.7_4.7-20111231-1_amd64.changes ACCEPTED into experimental
Accepted: cpp-4.7-doc_4.7-20111231-1_all.deb to main/g/gcc-4.7/cpp-4.7-doc_4.7-20111231-1_all.deb cpp-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/cpp-4.7_4.7-20111231-1_amd64.deb fixincludes_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/fixincludes_4.7-20111231-1_amd64.deb g++-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/g++-4.7-multilib_4.7-20111231-1_amd64.deb g++-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/g++-4.7_4.7-20111231-1_amd64.deb gcc-4.7-base_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gcc-4.7-base_4.7-20111231-1_amd64.deb gcc-4.7-doc_4.7-20111231-1_all.deb to main/g/gcc-4.7/gcc-4.7-doc_4.7-20111231-1_all.deb gcc-4.7-locales_4.7-20111231-1_all.deb to main/g/gcc-4.7/gcc-4.7-locales_4.7-20111231-1_all.deb gcc-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gcc-4.7-multilib_4.7-20111231-1_amd64.deb gcc-4.7-plugin-dev_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gcc-4.7-plugin-dev_4.7-20111231-1_amd64.deb gcc-4.7-source_4.7-20111231-1_all.deb to main/g/gcc-4.7/gcc-4.7-source_4.7-20111231-1_all.deb gcc-4.7_4.7-20111231-1.diff.gz to main/g/gcc-4.7/gcc-4.7_4.7-20111231-1.diff.gz gcc-4.7_4.7-20111231-1.dsc to main/g/gcc-4.7/gcc-4.7_4.7-20111231-1.dsc gcc-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gcc-4.7_4.7-20111231-1_amd64.deb gcc-4.7_4.7-20111231.orig.tar.gz to main/g/gcc-4.7/gcc-4.7_4.7-20111231.orig.tar.gz gccgo-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gccgo-4.7-multilib_4.7-20111231-1_amd64.deb gccgo-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gccgo-4.7_4.7-20111231-1_amd64.deb gfortran-4.7-doc_4.7-20111231-1_all.deb to main/g/gcc-4.7/gfortran-4.7-doc_4.7-20111231-1_all.deb gfortran-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gfortran-4.7-multilib_4.7-20111231-1_amd64.deb gfortran-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gfortran-4.7_4.7-20111231-1_amd64.deb gobjc++-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gobjc++-4.7-multilib_4.7-20111231-1_amd64.deb gobjc++-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gobjc++-4.7_4.7-20111231-1_amd64.deb gobjc-4.7-multilib_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gobjc-4.7-multilib_4.7-20111231-1_amd64.deb gobjc-4.7_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/gobjc-4.7_4.7-20111231-1_amd64.deb lib32gcc1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gcc1-dbg_4.7-20111231-1_amd64.deb lib32gcc1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gcc1_4.7-20111231-1_amd64.deb lib32gfortran3-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gfortran3-dbg_4.7-20111231-1_amd64.deb lib32gfortran3_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gfortran3_4.7-20111231-1_amd64.deb lib32go0-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32go0-dbg_4.7-20111231-1_amd64.deb lib32go0_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32go0_4.7-20111231-1_amd64.deb lib32gomp1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gomp1-dbg_4.7-20111231-1_amd64.deb lib32gomp1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32gomp1_4.7-20111231-1_amd64.deb lib32itm1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32itm1-dbg_4.7-20111231-1_amd64.deb lib32itm1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32itm1_4.7-20111231-1_amd64.deb lib32mudflap0-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32mudflap0-dbg_4.7-20111231-1_amd64.deb lib32mudflap0_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32mudflap0_4.7-20111231-1_amd64.deb lib32objc4-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32objc4-dbg_4.7-20111231-1_amd64.deb lib32objc4_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32objc4_4.7-20111231-1_amd64.deb lib32quadmath0-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32quadmath0-dbg_4.7-20111231-1_amd64.deb lib32quadmath0_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32quadmath0_4.7-20111231-1_amd64.deb lib32stdc++6-4.7-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32stdc++6-4.7-dbg_4.7-20111231-1_amd64.deb lib32stdc++6_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/lib32stdc++6_4.7-20111231-1_amd64.deb libgcc1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgcc1-dbg_4.7-20111231-1_amd64.deb libgcc1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgcc1_4.7-20111231-1_amd64.deb libgfortran3-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgfortran3-dbg_4.7-20111231-1_amd64.deb libgfortran3_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgfortran3_4.7-20111231-1_amd64.deb libgo0-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgo0-dbg_4.7-20111231-1_amd64.deb libgo0_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgo0_4.7-20111231-1_amd64.deb libgomp1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgomp1-dbg_4.7-20111231-1_amd64.deb libgomp1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libgomp1_4.7-20111231-1_amd64.deb libitm1-dbg_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libitm1-dbg_4.7-20111231-1_amd64.deb libitm1_4.7-20111231-1_amd64.deb to main/g/gcc-4.7/libitm1_4.7-20111231-1_amd64.deb
Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?
On 12/31/2011 01:34 AM, Vincent Lefevre wrote: On 2011-12-30 17:15:00 -0600, Jonathan Nieder wrote: No, I mean that packagers can but should not use Build-Depends: gcc-snapshot CC = gcc-snapshot Don't do that, then. you might say. But not providing a /usr/bin/gcc-snapshot wrapper provides people with a reminder to look's at README.Debian and not to do that. OK. Couldn't the wrapper detect that it is being used by a packager (e.g. because some environment variable is set by the build process) and output an error in such a case? A wrapper will never remind you using the new library paths at runtime. The snapshot package is meant to get early feedback about the development version of GCC, either for a rebuild test, or to easily test for compiler errors on porter boxes. It's not a package meant for regular development. I really prefer to have users either set environment variables or create the wrapper scripts on their own. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eff3283.4020...@debian.org
Bug#653002: marked as done (G++-4.6: internal compiler error: Segmentation fault (works on 4.5)segfault))
Your message dated Sat, 31 Dec 2011 17:50:04 +0100 with message-id 4eff3d3c.9010...@debian.org and subject line Re: G++-4.6: internal compiler error: Segmentation fault (works on 4.5)segfault) has caused the Debian Bug report #653002, regarding G++-4.6: internal compiler error: Segmentation fault (works on 4.5)segfault) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 653002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653002 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: g++-4.6 Version: 4.6.2-7 Severity: serious Tags: upstream Justification: Policy 10.1 (or whatever section that says g++ should not Will add debug file in a minute. /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..-g -O2 -g -DDEBUG -fvisibility=hidden -pthread-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT peer_connection_leech.lo -MD -MP -MF .deps/peer_connection_leech.Tpo -c -o peer_connection_leech.lo peer_connection_leech.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -g -O2 -g -DDEBUG -fvisibility=hidden -pthread -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT peer_connection_leech.lo -MD -MP -MF ..deps/peer_connection_leech.Tpo -c peer_connection_leech.cc -fPIC -DPIC -o .libs/peer_connection_leech.o peer_connection_leech.cc: In member function 'void torrent::PeerConnectiontype::event_read() [with torrent::Download::ConnectionType type = (torrent::Download::ConnectionType)2u]': peer_connection_leech.cc:356:1: internal compiler error: Segmentation fault -- System Information: Debian Release: 6.0.3 APT prefers testing APT policy: (1000, 'testing'), (1000, 'stable'), (995, 'stable'), (750, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.2-grsec--grs-ipv6-64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages g++-4.6 depends on: ii gcc-4.6 4.6.2-7 ii gcc-4.6-base4.6.2-7 ii libc6 2.13-21 ii libgmp102:5.0.2+dfsg-2 ii libmpc2 0.9-4 ii libmpfr43.1.0-3 ii libstdc++6-4.6-dev 4.6.2-7 ii zlib1g 1:1.2.3.4.dfsg-3 g++-4.6 recommends no packages. Versions of packages g++-4.6 suggests: ii g++-4.6-multilib4.6.2-7 ii gcc-4.6-doc none ii libstdc++6-4.6-dbg 4.6.2-7 -- no debconf information ---End Message--- ---BeginMessage--- Version: 4.6.2-8 Not reproducible with 4.6.2-8 and gcc-snapshot. ---End Message---
Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?
On 2011-12-31 17:04:19 +0100, Matthias Klose wrote: A wrapper will never remind you using the new library paths at runtime. At runtime? Do you mean that one needs to change the library path also for running the generated executable? The README.Debian file doesn't say anything like that. According to the README.Debian file, the wrapper is just what we need. The snapshot package is meant to get early feedback about the development version of GCC, either for a rebuild test, or to easily test for compiler errors on porter boxes. It's not a package meant for regular development. I really prefer to have users either set environment variables or create the wrapper scripts on their own. The package description doesn't say that it isn't for regular development. BTW, is there any reason why gcc-snapshot needs the library path to be changed explicitly (to run the compiler) while this is not needed for gcc-4.4, gcc-4.5, etc.? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231192441.gj5...@xvii.vinc17.org
Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?
Vincent Lefevre wrote: At runtime? Do you mean that one needs to change the library path also for running the generated executable? Yes, gcc-snapshot includes a snapshot of libgcc (and libstdc++, libgcj, libobjc, etc). So checking those libraries' behavior involves modifying the library path at runtime. From time to time the ABI can be bumped, which means the dependencies of generated executables need not always be satisfied by the ordinary copies of those libraries in /lib. The README.Debian file doesn't say anything like that. According to the README.Debian file, the wrapper is just what we need. Good catch, thanks. Can you suggest an improved wording? [...] BTW, is there any reason why gcc-snapshot needs the library path to be changed explicitly (to run the compiler) while this is not needed for gcc-4.4, gcc-4.5, etc.? The libraries in gcc-snapshot are private libraries, not meant to conflict with the libgcc1 et al packages nor to be used by ordinary programs like /bin/ls except when the user requests so by setting LD_LIBRARY_PATH. Cheers, Jonathan -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011123124.GA19577@elie.Belkin
Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?
On 2011-12-31 14:00:04 -0600, Jonathan Nieder wrote: Vincent Lefevre wrote: At runtime? Do you mean that one needs to change the library path also for running the generated executable? Yes, gcc-snapshot includes a snapshot of libgcc (and libstdc++, libgcj, libobjc, etc). So checking those libraries' behavior involves modifying the library path at runtime. OK, I thought that the static version was used in such a case, but I've now seen that the gcc doc (under -static-libgcc) says that it is not always possible (in particular for C++ and Java). Alternatively, couldn't /usr/lib/gcc-snapshot/lib be added to the run path instead of having to use LD_LIBRARY_PATH? For instance, having export LD_RUN_PATH=/usr/lib/gcc-snapshot/lib in the gcc-snapshot wrapper seems to work (I've done tests with mksh). Without this run path setting: $ ldd mksh linux-vdso.so.1 = (0x7fff829ff000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f159516a000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1594f54000) /lib64/ld-linux-x86-64.so.2 (0x7f159550d000) With this setting: $ ldd mksh linux-vdso.so.1 = (0x7fff69fff000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f85a6818000) libgcc_s.so.1 = /usr/lib/gcc-snapshot/lib/libgcc_s.so.1 (0x7f85a6603000) /lib64/ld-linux-x86-64.so.2 (0x7f85a6bbb000) without modifying LD_LIBRARY_PATH. From time to time the ABI can be bumped, which means the dependencies of generated executables need not always be satisfied by the ordinary copies of those libraries in /lib. I also suppose that there may be incompatilibities if the software compiled with gcc-snapshot is linked against libraries compiled with normal GCC versions (if they both use libgcc). The README.Debian file doesn't say anything like that. According to the README.Debian file, the wrapper is just what we need. Good catch, thanks. Can you suggest an improved wording? Let's first see what you think about the run path... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231214308.gk5...@xvii.vinc17.org
