[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Eric Gallager --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > --- Comment #8 from Jonathan Wakely --- > > Jay, is the original problem on SunOS still happening? > > > > Rainer, any insight into that build failure? Are some Solaris patches > > needed? > > I don't think so: both in Solaris 10 FCS and in current Solaris 11.4, > declares strsignal alike: > > extern char *strsignal(int); > > And for me, both HAVE_STRSIGNAL and HAVE_DECL_STRSIGNAL are defined as 1 > in gcc/auto-host.h. > > Jay needs to look at gcc/config.log in more detail to find why the > corresponding autoconf tests fail for him while they work here. Well, since Jay hasn't done so within 3 months of this having been put in WAITING, I'm closing this. Jay, feel free to reopen if you ever do find the additional details requested.
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jonathan Wakely --- > Jay, is the original problem on SunOS still happening? > > Rainer, any insight into that build failure? Are some Solaris patches needed? I don't think so: both in Solaris 10 FCS and in current Solaris 11.4, declares strsignal alike: extern char *strsignal(int); And for me, both HAVE_STRSIGNAL and HAVE_DECL_STRSIGNAL are defined as 1 in gcc/auto-host.h. Jay needs to look at gcc/config.log in more detail to find why the corresponding autoconf tests fail for him while they work here.
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 Jonathan Wakely changed: What|Removed |Added Target||sparc-sun-solaris2.10 CC||ro at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- Jay, is the original problem on SunOS still happening? Rainer, any insight into that build failure? Are some Solaris patches needed?
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #7 from Jonathan Wakely --- Try building a supported version of GCC. Nobody is going to fix anything in gcc 4.8.x now. The errors you;re getting are not the same as the ones on SunOS, I suspect you've copied a built GCC from one machine to another machine with a different libc. That won't work, you need to build GCC for the specific machine.
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #6 from Yves Caniou --- (In reply to Eric Gallager from comment #5) > (In reply to Yves Caniou from comment #4) > > I have the same issue with gcc-4.8.2 compiling gcc-4.8.2, on a Intel(R) > > Xeon(R) CPU E5-2630 0 @ 2.30GHz. > > What about with a newer, still-supported version? At the moment, I only have sys-devel/gcc v-7.3.0-r3 installed, and compiled with itself. The other supported version of gcc at the moment is 6.4.0-r1. What do you want me to try exactly?
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-07 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- (In reply to Yves Caniou from comment #4) > I have the same issue with gcc-4.8.2 compiling gcc-4.8.2, on a Intel(R) > Xeon(R) CPU E5-2630 0 @ 2.30GHz. What about with a newer, still-supported version?
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 Yves Caniou yves.can...@ens-lyon.fr changed: What|Removed |Added CC||yves.can...@ens-lyon.fr --- Comment #4 from Yves Caniou yves.can...@ens-lyon.fr --- I have the same issue with gcc-4.8.2 compiling gcc-4.8.2, on a Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz. First, compiling 4.8.2 from 4.7.2 (debian): no problem. I use gmp-5.1.3, mpfr-3.1.2, mpc-1.0.1. There are not intree. Once compiled, their respective prefix/lib are added to LD_LIBRARY_PATH. Gcc source is copied local disk, so no NFS or such. I call: /tmp/YC/gcc/src-4.8.2/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/home/ycaniou/bin/amd64/4.7.2/gcc --disable-altivec --disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-gmp=/home/ycaniou/bin/amd64/4.7.2/gmp --with-mpfr=/home/ycaniou/bin/amd64/4.7.2/mpfr --with-mpc=/home/ycaniou/bin/amd64/4.7.2/mpc Everything executes well after a make -j 8, and make install does its job. Compiling 4.8.2 with the new installed 4.8.2: . First, environment variables are updated: library path with 4.7.2_gcc-4.8.2_prefix/lib64 CPLUS include path with 4.7.2_gcc-4.8.2_prefix/include (I also tried with in addition include/c++/4.8.2, with same errors...) binary path with 4.7.2_gcc-4.8.2_prefix/bin . gmp-5.1.3, mpfr-3.1.2, mpc-1.0.1, not intree, are compiled with the 4.7.2_gcc-4.8.2 without any problem. And same steps are made: their respective 4.8.2_prefix/lib are added to LD_LIBRARY_PATH. GCC source on local disk. I call: /tmp/YC/gcc/src-4.8.2/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/home/ycaniou/bin/amd64/4.8.2/gcc --disable-altivec --disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-gmp=/home/ycaniou/bin/amd64/4.8.2/gmp --with-mpfr=/home/ycaniou/bin/amd64/4.8.2/mpfr --with-mpc=/home/ycaniou/bin/amd64/4.8.2/mpc And got the errors: x86_64-linux-gnu-g++ -c -DGENERATOR_FILE -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/tmp/YC/gcc/src-4.8.2/gcc -I/tmp/YC/gcc/src-4.8.2/gcc/. -I/tmp/YC/gcc/src-4.8.2/gcc/../include -I/tmp/YC/gcc/src-4.8.2/gcc/../libcpp/include -I/home/ycaniou/bin/amd64/4.8.2/gmp/include -I/home/ycaniou/bin/amd64/4.8.2/mpfr/include -I/home/ycaniou/bin/amd64/4.8.2/mpc/include -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libbacktrace /tmp/YC/gcc/src-4.8.2/gcc/gengtype.c -o gengtype.o In file included from /tmp/YC/gcc/src-4.8.2/gcc/gcc-ar.c:22:0: /tmp/YC/gcc/src-4.8.2/gcc/system.h:500:34: error: declaration of C function ‘const char* strsignal(int)’ conflicts with extern const char *strsignal (int); ^ In file included from /home/ycaniou/bin/amd64/4.7.2/gcc-4.8.2_install/include/c++/4.8.2/cstring:42:0, from /tmp/YC/gcc/src-4.8.2/gcc/system.h:205, from /tmp/YC/gcc/src-4.8.2/gcc/gcc-ar.c:22: /usr/include/string.h:566:14: error: previous declaration ‘char* strsignal(int)’ here extern char *strsignal (int __sig) __THROW; ^ In file included from /tmp/YC/gcc/src-4.8.2/gcc/system.h:645:0, from /tmp/YC/gcc/src-4.8.2/gcc/gcc-ar.c:22: /tmp/YC/gcc/src-4.8.2/gcc/../include/libiberty.h:110:36: error: new declaration ‘char* basename(const char*)’ extern char *basename (const char *); ^ In file included from /home/ycaniou/bin/amd64/4.7.2/gcc-4.8.2_install/include/c++/4.8.2/cstring:42:0, from /tmp/YC/gcc/src-4.8.2/gcc/system.h:205, from /tmp/YC/gcc/src-4.8.2/gcc/gcc-ar.c:22: /usr/include/string.h:603:28: error: ambiguates old declaration ‘const char* basename(const char*)’ extern C++ __const char *basename (__const char *__filename)
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #1 from Jay jay.krell at cornell dot edu 2013-03-23 23:12:03 UTC --- I see that the check for any function involves a cast of its type -- i.e. it isn't customized per-function, so a change isn't trivial. For now I have removed strstr and strsignal from system.h -- assume they are declared.
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-23 23:18:09 UTC --- What options did you use to configure GCC? Also are you building gmp/mpfr in the same tree?
[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703 --- Comment #3 from Jay jay.krell at cornell dot edu 2013-03-23 23:24:55 UTC --- gmp/mpfr/mpc are in-tree Notice that it has gotten past the first stage..so I didn't bother double checking what my bootstrap compiler was..though gcc/g++ 3.x is in $PATH. Very simple configure line -- just setting -prefix. jkrell@unstable10s [unstable10s]:~/obj/gcc480-sparc-sun-solaris2.10/gcc head ../config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ /home/jkrell/src/gcc-4.8.0/configure -prefix=/home/jkrell/gcc480-sparc-sun-solaris2.10
