Bug#372557: gcc-3.3: segmentation fault of ld when compiling binary file with gcc
Package: gcc-3.3 Version: 1:3.3.5-13 Severity: minor Compiling a binary file (which is not possible) cause ld to segmentation fault. $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) $ make cc -pg -fprofile-arcs -ftest-coverage hello.c -o hello $ gcc hello collect2: ld terminated with signal 11 [Segmentation fault] hello(.rodata+0x0): multiple definition of `_fp_hw' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.rodata+0x0):../sysdeps/i386/elf/start.S:65: first defined here hello(.init+0x0): In function `_init': /disk/hdc2/glibc/debian-build/glibc_2.3.5-6.build1/glibc-2.3.5/build-tree/i386-libc/csu/crti.S:36: multiple definition of `_init' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o(.init+0x0):/disk/hdc2/glibc/debian-build/glibc_2.3.5-6.build1/glibc-2.3.5/build-tree/i386-libc/csu/crti.S:12: first defined here hello(.text+0x0): In function `_start': .../sysdeps/i386/elf/start.S:65: multiple definition of `_start' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.text+0x0):../sysdeps/i386/elf/start.S:65: first defined here hello(.fini+0x0): In function `_fini': /disk/hdc2/glibc/debian-build/glibc_2.3.5-6.build1/glibc-2.3.5/build-tree/i386-libc/csu/crti.S:52: multiple definition of `_fini' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o(.fini+0x0): first defined here hello(.got+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.got.plt+0x0):../sysdeps/i386/elf/start.S:65: first defined here hello(.rodata+0x4): multiple definition of `_IO_stdin_used' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.rodata+0x4):../sysdeps/i386/elf/start.S:71: first defined here hello(.data+0x0): In function `__data_start': : multiple definition of `__data_start' /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.data+0x0):../sysdeps/i386/elf/start.S:65: first defined here /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.dynamic+0x0):../sysdeps/i386/elf/start.S:65: multiple definition of `_DYNAMIC' hello(.dynamic+0x0): first defined here $ -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15.4 Locale: LANG=hu_HU, LC_CTYPE=hu_HU (charmap=ISO-8859-2) Versions of packages gcc-3.3 depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii cpp-3.3 1:3.3.5-13 The GNU C preprocessor ii gcc-3.3-base 1:3.3.5-13 The GNU Compiler Collection (base ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-2 GCC support library -- no debconf information hello-gcov.tar.bz2 Description: BZip2 compressed data
Processed: Re: Bug#372557: gcc-3.3: segmentation fault of ld when compiling binary file with gcc
Processing commands for [EMAIL PROTECTED]: > reassign 372557 binutils Bug#372557: gcc-3.3: segmentation fault of ld when compiling binary file with gcc Bug reassigned from package `gcc-3.3' to `binutils'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372557: gcc-3.3: segmentation fault of ld when compiling binary file with gcc
reassign 372557 binutils thanks > Compiling a binary file (which is not possible) cause ld to > segmentation fault. ld is binutils' domain. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#372559: gecode: FTBFS with g++-4.1: no suitable operator
Processing commands for [EMAIL PROTECTED]: > reassign 372559 g++-4.1 Bug#372559: gecode: FTBFS with g++-4.1: no suitable operator Bug reassigned from package `gecode' to `g++-4.1'. > merge 372559 372152 Bug#372152: g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) issue) Bug#372559: gecode: FTBFS with g++-4.1: no suitable operator Merged 372152 372559. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tag gcc report
Processing commands for [EMAIL PROTECTED]: > tags 372152 + pending Bug#372152: g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) issue) There were no tags set. Bug#372559: gecode: FTBFS with g++-4.1: no suitable operator Tags added: pending > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
tag 23 patch thanks dude On Sat, Jan 07, 2006, Matthias Klose wrote: > I do not intend to work on it until summer, when it becomes clear > which compiler versions are included in etch. maybe these are 2.95, > 3.4 and 4.1. who knows ... > > I'm happy to include any patches before that, if you are volunteering > ;-) Some things are already prepared in the packaging. Hi Matthias, and thanks for the time you're spending on gcc's and python's transitions! Now that we know gcc 4.1 is going to be the default version in Etch, maybe it is time to get rid of this old bug. Here is a cpp.1 based on the help output of cpp (and on the help2man command) that may be considered as a free interim replacement until we have an exhaustive free documentation for GCC. Do you think it will help? Do you want me to work on other manpages from the --help output? I can imagine that you are very busy currently, but please just drop a note to let me know if I can work on it during the current BSP in Paris. Regards, -- adn Mohammed Adnène Trojette .TH CPP 1 "2006-06-04" "gcc-4.1.2" "GNU" .SH NAME cpp \- The C Preprocessor .SH SYNOPSIS .B cpp [\fIoptions\fR] \fIfile\fR... .SH OPTIONS .TP \fB\-pass\-exit\-codes\fR Exit with highest error code from a phase .TP \fB\-\-help\fR Display this information .TP \fB\-\-target\-help\fR Display target specific command line options .IP (Use '\-v \fB\-\-help\fR' to display command line options of sub\-processes) .TP \fB\-dumpspecs Display all of the built in spec strings .TP \fB\-dumpversion Display the version of the compiler .TP \fB\-dumpmachine Display the compiler's target processor .TP \fB\-print\-search\-dirs Display the directories in the compiler's search path .TP \fB\-print\-libgcc\-file\-name Display the name of the compiler's companion library .TP \fB\-print\-file\-name= Display the full path to library .TP \fB\-print\-prog\-name= Display the full path to compiler component .TP \fB\-print\-multi\-directory Display the root directory for versions of libgcc .TP \fB\-print\-multi\-lib Display the mapping between command line options and .IP multiple library search directories .HP \fB\-print\-multi\-os\-directory\fR Display the relative path to OS libraries .TP \fB\-Wa\fR, Pass comma\-separated on to the assembler .TP \fB\-Wp\fR, Pass comma\-separated on to the preprocessor .TP \fB\-Wl\fR, Pass comma\-separated on to the linker .TP \fB\-Xassembler\fR Pass on to the assembler .TP \fB\-Xpreprocessor\fR Pass on to the preprocessor .TP \fB\-Xlinker\fR Pass on to the linker .TP \fB\-combine\fR Pass multiple source files to compiler at once .TP \fB\-save\-temps\fR Do not delete intermediate files .TP \fB\-pipe\fR Use pipes rather than intermediate files .TP \fB\-time\fR Time the execution of each subprocess .TP \fB\-specs=\fR Override built\-in specs with the contents of .TP \fB\-std=\fR Assume that the input sources are for .TP \fB\-\-sysroot=\fR Use as the root directory for headers for headers and libraries .TP \fB\-B\fR Add to the compiler's search paths .TP \fB\-b\fR Run gcc for target , if installed .TP \fB\-V\fR Run gcc version number , if installed .TP \fB\-v\fR Display the programs invoked by the compiler .TP \-### Like \fB\-v\fR but options quoted and commands not executed .TP \fB\-E\fR Preprocess only; do not compile, assemble or link .TP \fB\-S\fR Compile only; do not assemble or link .TP \fB\-c\fR Compile and assemble, but do not link .TP \fB\-o\fR Place the output into .TP \fB\-x\fR Specify the language of the following input files Permissible languages include: c c++ assembler none \&'none' means revert to the default behavior of guessing the language based on the file's extension .PP Options starting with \fB\-g\fR, \fB\-f\fR, \fB\-m\fR, \fB\-O\fR, \fB\-W\fR, or \fB\-\-param\fR are automatically passed on to the various sub\-processes invoked by cpp. In order to pass other options on to these processes the \fB\-W\fR options must be used. .PP For bug reporting instructions, please see: http://gcc.gnu.org/bugs.html>. For Debian GNU/Linux specific bug reporting instructions, please see: . .SH COPYRIGHT Copyright \(co 2006 Free Software Foundation, Inc. .br This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. .SH "SEE ALSO" The full documentation for .B cpp is maintained as a Texinfo manual. If the .B info and .B cpp programs are properly installed at your site, the command .IP .B info cpp .PP should give you access to the complete manual.
Processed: Re: Bug#200003: Any progress?
Processing commands for [EMAIL PROTECTED]: > tag 23 patch Bug#23: [NONFREE-DOC:UNMODIFIABLE] cpp: contains non-free manpages Tags were: sarge-ignore Tags added: patch > thanks dude Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#200003: Any progress?
Processing commands for [EMAIL PROTECTED]: > tags 23 - patch Bug#23: [NONFREE-DOC:UNMODIFIABLE] cpp: contains non-free manpages Tags were: patch sarge-ignore Tags removed: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
tags 23 - patch thanks Mohammed Adnène Trojette writes: > tag 23 patch > thanks dude > > On Sat, Jan 07, 2006, Matthias Klose wrote: > > I do not intend to work on it until summer, when it becomes clear > > which compiler versions are included in etch. maybe these are 2.95, > > 3.4 and 4.1. who knows ... > > > > I'm happy to include any patches before that, if you are volunteering > > ;-) Some things are already prepared in the packaging. > > Now that we know gcc 4.1 is going to be the default version in Etch, > maybe it is time to get rid of this old bug. > > Here is a cpp.1 based on the help output of cpp (and on the help2man > command) that may be considered as a free interim replacement until we > have an exhaustive free documentation for GCC. > > Do you think it will help? Do you want me to work on other manpages > from the --help output? Mohammed, thanks for your help. It's certainly valueable to have manual pages in main. If you do want to go this way, we need replacements for _all_ manual pages. The second thing is to remove the gfdl'd texi files from the sources, so that the package still builds. The idea is to replace these files with dummy content, such that the build still succeds and the Makefile don't have to be patched. The files in question are in: gcc/doc/* gcc/doc/include/* gcc/gfortran/gfortran.texi gcc/java/gcj.texi gcc/ada/gnat-style.texi gcc/ada/gnat_rm.texi gcc/ada/gnat_ugn.texi gcc/fortran/invoke.texi gcc/fortran/intrinsic.texi gcc/fortran/gfortran.texi gcc/treelang/treelang.texi libstdc++-v3/docs/html/17_intro/porting.texi libiberty/*.texi Most of the files in gcc/doc/, gcc/doc/include/, libiberty/ can be replaced by en empty file (or better having just a comment). The man pages are generated from some texi files, so there must be some infrastructure kept (see gcc/java/gcj.texi to start with the worst one). Of course you could write your new manual pages as texi documents as well. A patch should be a tarball of all these new files. Matthias
[bts-link] source package gcc-snapshot
# # bts-link upstream status pull for source package gcc-snapshot # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #367866 # * http://gcc.gnu.org/PR27979 # * remote status changed: (?) -> NEW usertags 367866 + status-NEW # remote status report for #369606 # * http://gcc.gnu.org/PR27830 # * remote status changed: NEW -> ASSIGNED usertags 369606 - status-NEW usertags 369606 + status-ASSIGNED thanks
Bug#200003: Any progress?
Matthias Klose <[EMAIL PROTECTED]> writes: > The second thing is to remove the gfdl'd texi files from the sources, > so that the package still builds. The idea is to replace these files > with dummy content, such that the build still succeds and the Makefile > don't have to be patched. Unless I am mistaken, there was a Debian General Resolution lately that allows GFDL'd documents in main, provided they have no front-cover text, no back-cover text and no invariants. I am concerned that wholesale deletion of all documentation from the GCC package is a disservice to users. Should we not rather assess each document individually and remove only those that fail the General Resolution criteria? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#200003: Any progress?
On Sat, Jun 10, 2006, Ludovic Brenta wrote: > Unless I am mistaken, there was a Debian General Resolution lately > that allows GFDL'd documents in main, provided they have no > front-cover text, no back-cover text and no invariants. I am > concerned that wholesale deletion of all documentation from the GCC > package is a disservice to users. Should we not rather assess each > document individually and remove only those that fail the General > Resolution criteria? All of them actually front and back cover texts, as far as I am reading right now in the texi files. Don't forget the documentation will be available in non-free as soon as a package is ready. And don't be afraid, we won't be throwing out of main DFSG free documentation ;) -- adn Mohammed Adnène Trojette
Bug#200003: Any progress?
Ludovic Brenta writes: > Matthias Klose <[EMAIL PROTECTED]> writes: > > The second thing is to remove the gfdl'd texi files from the sources, > > so that the package still builds. The idea is to replace these files > > with dummy content, such that the build still succeds and the Makefile > > don't have to be patched. > > Unless I am mistaken, there was a Debian General Resolution lately > that allows GFDL'd documents in main, provided they have no > front-cover text, no back-cover text and no invariants. I am > concerned that wholesale deletion of all documentation from the GCC > package is a disservice to users. Should we not rather assess each > document individually and remove only those that fail the General > Resolution criteria? sure, are there any? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372605: FTBFS: parse.y: conflicts: 62 shift/reduce, 25 reduce/reduce
Package: gcc-4.1 Version: 4.1.1-2 Severity: serious Hello, It seems that currently gcc-4.1 is uncompilable: gnatgcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Wno-traditional -o xgpc p/gpc.o prefix.o version.o \ intl.o ../libcpp/libcpp.a ../libiberty/libiberty.a gnatgcc -o p/diagnostic.o -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ip -I../../src/gcc -I../../src/gcc/p -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I. -Ip -I../../src/gcc -I../../src/gcc/p -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -DGPC ../../src/gcc/diagnostic.c cd ../../src/gcc/p && bison -o parse.c parse.y parse.y: conflicts: 62 shift/reduce, 25 reduce/reduce parse.y: expected 24 reduce/reduce conflicts make[4]: *** [../../src/gcc/p/parse.h] Error 1 make[4]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build/gcc' make[3]: *** [stage1_build] Error 2 make[3]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build/gcc' make[2]: *** [bootstrap] Error 2 make[2]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build' s=`cat status`; rm -f status; test $s -eq 0 make[1]: *** [stamps/05-build-stamp] Error 1 make[1]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1' make: *** [stamps/05-build-stamp] Error 2 Cheers, -- Julien Danjou // <[EMAIL PROTECTED]> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // There is nothing under this line. signature.asc Description: Digital signature
Bug#372605: FTBFS: parse.y: conflicts: 62 shift/reduce, 25 reduce/reduce
ok, looks like bison-2.3 breaks gpc. investigating ... > Package: gcc-4.1 > Version: 4.1.1-2 > Severity: serious > > Hello, > > It seems that currently gcc-4.1 is uncompilable: > > gnatgcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic > -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute-DHAVE_CONFIG_H -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long > -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute > -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute -Wno-traditional -o xgpc p/gpc.o prefix.o > version.o \ > intl.o ../libcpp/libcpp.a ../libiberty/libiberty.a > gnatgcc -o p/diagnostic.o -c -g -DENABLE_CHECKING > -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ip > -I../../src/gcc -I../../src/gcc/p -I../../src/gcc/../include > -I../../src/gcc/../libcpp/include -I. -Ip -I../../src/gcc > -I../../src/gcc/p -I../../src/gcc/../include > -I../../src/gcc/../libcpp/include -DGPC ../../src/gcc/diagnostic.c > cd ../../src/gcc/p && bison -o parse.c parse.y > parse.y: conflicts: 62 shift/reduce, 25 reduce/reduce > parse.y: expected 24 reduce/reduce conflicts > make[4]: *** [../../src/gcc/p/parse.h] Error 1 > make[4]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build/gcc' > make[3]: *** [stage1_build] Error 2 > make[3]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build/gcc' > make[2]: *** [bootstrap] Error 2 > make[2]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1/build' > s=3D`cat status`; rm -f status; test $s -eq 0 > make[1]: *** [stamps/05-build-stamp] Error 1 > make[1]: Leaving directory `/home/staff/jd/gcc-4.1-4.1.1' > make: *** [stamps/05-build-stamp] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with g++-4.1
Brendan O'Dea writes: > On Thu, Jun 08, 2006 at 03:44:46PM +0200, Martin Michlmayr wrote: > >* Matthias Klose <[EMAIL PROTECTED]> [2006-06-08 14:50]: > >> Martin, maybe we can add a workaround in the Perl headers instead? > > > >I'm sure bod could just remove the use of 'register' for a while. > > Sure I can, but... > > I've just tested building libapt-pkg-perl, which is C++ and uses pTHX > (the macro for my_perl which includes register) in utils.c without > problems. you can find a compiler exposing the problem at: deb http://people.debian.org/~doko/gcc-4.1 ./ Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
