Bootstraping the compiler results in a compilation error during libstdc++ build: $ ./gcc-3.4.0/configure --enable-languages=c,c++ [...] $ gmake bootstrap [...] /a61/tmp/build-gcc-3.4.0/gcc/xgcc -shared-libgcc -B/a61/tmp/build-gcc-3.4.0/gcc/ -nostdinc++ -L/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/src -L/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/src/.libs -B/usr/local/alphaev5-dec-osf5.0/bin/ -B/usr/local/alphaev5-dec-osf5.0/lib/ -isystem /usr/local/alphaev5-dec-osf5.0/include -isystem /usr/local/alphaev5-dec-osf5.0/sys-include -I/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/alphaev5-dec-osf5.0 -I/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include -I/a61/tmp/gcc-3.4.0/libstdc++-v3/libsupc++ -O2 -g -O2 -mieee -g -O2 -mieee -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -c ../../../../gcc-3.4.0/libstdc++-v3/src/allocator.cc -DPIC -o .libs/allocator.o In file included from /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/bits/postypes.h:46, from /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/iosfwd:50, from /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/bits/stl_algobase.h:70, from /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/memory:54, from ../../../../gcc-3.4.0/libstdc++-v3/src/allocator.cc:35: /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/cwchar:182: error: `::wcsftime' has not been declared /a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/cwchar:193: error: `::wcstok' has not been declared [...] $ uname -a OSF1 a61.iue.tuwien.ac.at V5.0 910 alpha Seems to be related to following patch - which should actually fix exactly this error, but obviously doesn't: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00495.html
Hmm, the patch was 5.1 so it must have missed something in the headers for 5.0. What I suggest is you provide the preprocessed source with -save-temps -dD which gives the defines also. Then maybe we can fix this again with another fixincludes patch.
Created attachment 6591 [details] preprocessed source of the file generating the '::wcsftime' compile error
Yes it looks like the fixinclude fix did not fix this case: extern size_t __wcsftime_unix98 (wchar_t *, size_t, const wchar_t *, const struct tm *); But we still need more information as not everyone has access to the headers which is why I had asked for the preprocessed source file when you supplied -dD which also keeps the defines.
OSF is not a primary platform; postponed until GCC 3.4.2.
Resetting target milestone.
Well, I did supply -dD to generate the attached file, however it doesn't change anything. This was the exact command line I used: a61/tmp/build-gcc-3.4.0/gcc/xgcc -save-temps -dD -shared-libgcc -B/a61/tmp/build-gcc-3.4.0/gcc/ -nostdinc++ -L/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/src -L/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/src/.libs -B/usr/local/alphaev5-dec-osf5.0/bin/ -B/usr/local/alphaev5-dec-osf5.0/lib/ -isystem /usr/local/alphaev5-dec-osf5.0/include -isystem /usr/local/alphaev5-dec-osf5.0/sys-include -I/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include/alphaev5-dec-osf5.0 -I/a61/tmp/build-gcc-3.4.0/alphaev5-dec-osf5.0/libstdc++-v3/include -I/a61/tmp/gcc-3.4.0/libstdc++-v3/libsupc++ -O2 -g -O2 -mieee -g -O2 -mieee -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -c ../../../../gcc-3.4.0/libstdc++-v3/src/allocator.cc -DPIC -o .libs/allocator.o Did I miss something? -Rainer
Subject: Re: [3.4/3.5 Regression] bootstrap fails during bulding libstdc++-v3 on Tru64 V5.0 sabelka at iue dot tuwien dot ac dot at writes: > Well, I did supply -dD to generate the attached file, however it doesn't > change anything. This was the exact command line I used: [...] > Did I miss something? Using -dD doesn't work for me either. Using -g3 instead (which has the same effect), I see that -dD should be passed to the cc1 -E invocation, but is only passed to cc1 instead, where it has no effect. Instead of trying to get preprocessed output, just attach a copy of /usr/include/wchar.h (and perhaps the fixincluded wchar.h from the gcc build or install tree). If fixincludes doesn't fix up the V5.0 (it's V5.0, not V5.0A?) correctly, I'll need that file anyway to tweak the fixing process. Rainer
Rainer, it seems, that fixincludes doesn't fix up the file wchar.h at all on OSF V5.0 (at least I cannot see wchar.h in the gcc/include/ directory). And yes, I'm not on 5.0A: $ sizer -v Digital UNIX V5.0 (Rev. 910); Mon May 15 21:08:33 CEST 2000 -Rainer
Subject: Re: [3.4/3.5 Regression] bootstrap fails during bulding libstdc++-v3 on Tru64 V5.0 sabelka at iue dot tuwien dot ac dot at writes: > it seems, that fixincludes doesn't fix up the file wchar.h at all > on OSF V5.0 (at least I cannot see wchar.h in the gcc/include/ directory). Indeed: the V5.0 file is much closer to the one from V4.0F, but sufficiently different for the current alpha_wchar hack not to apply. I'll try to update that hack accordingly. Rainer
Postponed until GCC 3.4.3.
Postponed until GCC 3.4.4.
Any news on this bug?
Removing target milestone per: <http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html>. This does not effect any of the primary or secondary targets.
Alpha is not a primary or secondary target; removing target milestone.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Closing 4.1 branch.
Am having problem with libstdc++-v3 during bootrap of gcc 4.3.1 on Tru64 V5.1. gfortran and gcc built fine. (with --enable-languages=c,fortran to override the default list of c,c++,fortran,objc). The last working g++ was 3.4.3 but am currently using gcc 4.3.1 to boostrap the whole thing again and see. The error looks different so I'll likely file a separate bug if it still doesn't work.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
4.3 branch is being closed, moving to 4.4.7 target.
I don't even have V5.0 media, and anything before V5.1 is deprecated since GCC 4.5, so closing as won't fix. Rainer