[Bug bootstrap/28745] New: make bootstrap failed on rhel4-x64 with ld internal error at elf64-x86-64.c line 1912
/s rc' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/scottra/src/bld/x86_64-redhat-linux/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/scottra/src/bld/x86_64-redhat-linux/libstdc++-v3' make[2]: *** [all-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/home/scottra/src/bld' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/scottra/src/bld' make: *** [bootstrap] Error 2 -- Summary: make bootstrap failed on rhel4-x64 with ld internal error at elf64-x86-64.c line 1912 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: waspswarm at gmail dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28745
[Bug bootstrap/28745] make bootstrap failed on rhel4-x64 with ld internal error at elf64-x86-64.c line 1912
--- Comment #1 from waspswarm at gmail dot com 2006-08-15 20:22 --- [EMAIL PROTECTED] bld]$ uname -r 2.6.9-34.0.1.ELsmp [EMAIL PROTECTED] bld]$ cat /etc/redhat-release CentOS release 4.3 (Final) [EMAIL PROTECTED] bld]$ rpm -qa |grep binutils binutils-2.15.92.0.2-18 [EMAIL PROTECTED] bld]$ rpm -qa |grep glibc glibc-devel-2.3.4-2.19 glibc-2.3.4-2.19 glibc-kernheaders-2.4-9.1.98.EL glibc-2.3.4-2.19 glibc-headers-2.3.4-2.19 glibc-common-2.3.4-2.19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28745
[Bug bootstrap/28745] make bootstrap failed on rhel4-x64 with ld internal error at elf64-x86-64.c line 1912
--- Comment #3 from waspswarm at gmail dot com 2006-08-16 14:38 --- (In reply to comment #2) > This is a bug in binutils version which you are using. Either report this to > Redhat or update the version since the version that redhat uses is about 2 > years old and a prerelease. > I updated binutils to 2.17 and things built fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28745
[Bug c++/28975] New: conflicting declaration 'typedef struct mbstate_t mbstate_t'
When compiling the following test application with g++ and -D__STDC_VERSION__=199901 I receive errors about duplicate declarations. $ uname -a HP-UX yellow B.11.23 U ia64 1794711014 unlimited-user license // g++ -o test.o -g -O2 -mlp64 -D__STDC_VERSION__=199901 -c testmbstate.cpp // remove -D__STDC_VERSION__=199901 and it compiles cleanly #include int main(int argc, char** argv) { return 0; } $ g++ -v -o test.o -g -O2 -mlp64 -D__STDC_VERSION__=199901 -c testmbsta> Using built-in specs. Target: ia64-hp-hpux11.23 Configured with: ../gcc-4.1.1/configure --enable-checking=release --disable-shared --enable-threads=posix --disable-nls --enable-c99 --enable-languages=c,c++ : (reconfigured) ../gcc-4.1.1/configure --enable-checking=release --disable-shared --enable-threads=posix --disable-nls --enable-c99 --enable-languages=c,c++ --with-gnu-as --with-as=/opt/hp-gcc/bin/as --without-gnu-ld Thread model: posix gcc version 4.1.1 /usr/local/libexec/gcc/ia64-hp-hpux11.23/4.1.1/cc1plus -quiet -v -D__STDC_VERSION__=199901 testmbstate.cpp -quiet -dumpbase testmbstate.cpp -mlp64 -auxbase-strip test.o -g -O2 -version -o /var/tmp//ccLUuqb0.s ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../ia64-hp-hpux11.23/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1 /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/ia64-hp-hpux11.23 /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/backward /usr/local/include /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/include /usr/include End of search list. GNU C++ version 4.1.1 (ia64-hp-hpux11.23) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 8d13e28aaeb67511ccb5485a483e1cbb /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/cwchar:66: error: conflicting declaration 'typedef struct mbstate_t mbstate_t' /usr/include/sys/_mbstate_t.h:15: error: 'mbstate_t' has a previous declaration as 'typedef struct mbstate_t mbstate_t' -- Summary: conflicting declaration 'typedef struct mbstate_t mbstate_t' Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: waspswarm at gmail dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28975
[Bug c++/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'
--- Comment #1 from waspswarm at gmail dot com 2006-09-07 15:39 --- Here is /usr/include/sys/_mbstate_t.h /* * @(#)B11.23_LR */ #ifndef _MBSTATE_T_INCLUDED #define _MBSTATE_T_INCLUDED # ifndef _MBSTATE_T # define _MBSTATE_T typedef struct { unsigned char __parse_size:3; unsigned char __dummy:4; unsigned char __shift_state:1; char __parse_buf[7]; } mbstate_t; # endif #endif /* _MBSTATE_T_INCLUDED */ Here is the section of /usr/local/include/c++/4.1.1/cwchar around line 66: // Need to do a bit of trickery here with mbstate_t as char_traits // assumes it is in wchar.h, regardless of wchar_t specializations. #ifndef _GLIBCXX_HAVE_MBSTATE_T extern "C" { typedef struct { int __fill[6]; } mbstate_t; } #endif namespace std { using ::mbstate_t; } -- waspswarm at gmail dot com changed: What|Removed |Added CC| |waspswarm at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28975
[Bug target/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'
--- Comment #3 from waspswarm at gmail dot com 2006-09-07 15:46 --- (In reply to comment #2) > So that means when __STDC_VERSION__=199901 then _GLIBCXX_HAVE_MBSTATE_T needs > to be defined or something like that. > > Anyways this is a target issue. > Thanks! Adding -D_GLIBCXX_HAVE_MBSTATE_T to the compile line gets around the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28975