https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238
--- Comment #4 from Mike <programmist.linuks at mail dot ru> --- (In reply to Richard Biener from comment #3) > So if comment #5 is correct then it seems we are building stage1 genmatch > against the (not yet built) libstdc++ headers but linking > (-static-libstdc++) against the host compilers library. > > Unfortunately the provided log doesn't tell how build/genmatch.o was built. > > Trying myself we do (correctly): > > g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild > -I/space/rguenther/src/svn/gcc-6-branch/gcc > -I/space/rguenther/src/svn/gcc-6-branch/gcc/build > -I/space/rguenther/src/svn/gcc-6-branch/gcc/../include > -I/space/rguenther/src/svn/gcc-6-branch/gcc/../libcpp/include \ > -o build/genmatch.o > /space/rguenther/src/svn/gcc-6-branch/gcc/genmatch.c > > and in my experiments I can compile GCC 6.3 with 4.9.2 just fine so maybe > Debian backported some changes in a wrong way. I suggest to report this bug > to Debian instead (CCing packager). > > Note that you seem to do a build in-tree which isn't recommended. Can you > try to build in a separate object directory instead? I tried to compile by your method and this is what happened: <<< root@mx:/home/admin/sources/gcc-6.3.0# g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I./gcc -I./gcc/build -I./gcc/../include -I./gcc/../libcpp/include -o build/genmatch.o ./gcc/genmatch.c./gcc/genmatch.c:24:21: fatal error: bconfig.h: No such file or directory #include "bconfig.h" ^ compilation terminated.>>> > Can you try to build in a separate object directory instead? And where to put the folder? I started looking for configuration files: <<< root@mx:/home/admin/sources/gcc-6.3.0# find . -iname bconfig.h ./host-x86_64-pc-linux-gnu/gcc/bconfig.h ./host-x86_64-pc-linux-gnu/prev-gcc/bconfig.h >>> I added a new path for Include: <<< root@mx:/home/admin/sources/gcc-6.3.0# g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I./gcc -I./gcc/build -I./gcc/../include -I./gcc/../libcpp/include -I./host-x86_64-pc-linux-gnu/gcc -o build-x86_64-linux-gnu/genmatch.o ./gcc/genmatch.c root@mx:/home/admin/sources/gcc-6.3.0# ls build-x86_64-linux-gnu/ fixincludes genmatch.o libcpp libiberty -rw-r--r-- 1 root root 1,2M мар 30 13:26 build-x86_64-linux-gnu/genmatch.o >>> Here is my old file! <<< root@mx:/home/admin/sources/gcc-6.3.0# ls -lh ./host-x86_64-pc-linux-gnu/gcc/build/genmatch.o -rw-r--r-- 1 root root 298K мар 22 18:27 ./host-x86_64-pc-linux-gnu/gcc/build/genmatch.o >>> I went to the folder in which the compilation takes place: <<< root@mx:/home/admin/sources/gcc-6.3.0# cd ./host-x86_64-pc-linux-gnu/gcc/ >>> An error occurs after this command: <<< root@mx:/home/admin/sources/gcc-6.3.0/host-x86_64-pc-linux-gnu/gcc# g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -fno-pie -o build/genmatch \ > build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a > build/errors.o build/vec.o build/hash-table.o > ../../host-x86_64-pc-linux-gnu/libiberty/libiberty.a build/vec.o: In function `vec_prefix::release_overhead(void*, unsigned long, bool)': vec.c:(.text+0x6c6): undefined reference to `operator delete(void*, unsigned long)' build/vec.o: In function `vec_prefix::register_overhead(void*, unsigned long, unsigned long)': vec.c:(.text+0x9a1): undefined reference to `operator delete(void*, unsigned long)' build/vec.o: In function `mem_alloc_description<vec_usage>::~mem_alloc_description()': vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x62): undefined reference to `operator delete(void*, unsigned long)' vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x70): undefined reference to `operator delete(void*, unsigned long)' vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x101): undefined reference to `operator delete(void*, unsigned long)' build/vec.o:vec.c:(.text._ZN21mem_alloc_descriptionI9vec_usageED2Ev[_ZN21mem_alloc_descriptionI9vec_usageED5Ev]+0x14e): more undefined references to `operator delete(void*, unsigned long)' follow collect2: error: ld returned 1 exit status >>>