[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 vries at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from vries at gcc dot gnu.org --- Committed patch that removes configure option --with-host-libstdcxx. Marking resolved-fixed.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #15 from vries at gcc dot gnu.org --- Author: vries Date: Wed Aug 12 15:13:35 2015 New Revision: 226819 URL: https://gcc.gnu.org/viewcvs?rev=226819&root=gcc&view=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries PR other/67092 PR other/67098 * configure.ac: Remove --with_host_libstdcxx support. * configure: Regenerate. * doc/install.texi: Remove --with_host_libstdcxx item. Update --with-stage1-libs, --with-boot-ldflags and --with-boot-libs items accordingly. Mention default for --with-stage1-ldflags. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #14 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00603.html
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #13 from Richard Biener --- I think we can no longer reliably support host libstdc++ as includes are not picked up from its location and GCC is C++ now. I suggest to remove that entirely.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #12 from vries at gcc dot gnu.org --- (In reply to vries from comment #11) > (In reply to vries from comment #10) > > Looking at the description of with-host-libstdcxx: > > ... > > --with-host-libstdcxx=linker-args > > If you are linking with a static copy of PPL, you can use this option to > > specify how the linker should find the standard C++ library used internally > > by PPL. Typical values of linker-args might be ‘-lstdc++’ or > > ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy > > of PPL, you probably do not need this option; shared library dependencies > > will cause the linker to search for the standard C++ library automatically. > > ... > > > > We no longer support building with PPL ( > > https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item > > probably needs to be updated. > > --with-host-libstdcxx=linker-args > Sets default value for --with-stage1-libs and --with-boot-libs. Sets default > value for --with-boot-ldflags to empty. Filed seperate PR67099 - Documentation --with-host-libstdcxx is outdated, mentions ppl .
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #11 from vries at gcc dot gnu.org --- (In reply to vries from comment #10) > Looking at the description of with-host-libstdcxx: > ... > --with-host-libstdcxx=linker-args > If you are linking with a static copy of PPL, you can use this option to > specify how the linker should find the standard C++ library used internally > by PPL. Typical values of linker-args might be ‘-lstdc++’ or > ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy > of PPL, you probably do not need this option; shared library dependencies > will cause the linker to search for the standard C++ library automatically. > ... > > We no longer support building with PPL ( > https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item > probably needs to be updated. --with-host-libstdcxx=linker-args Sets default value for --with-stage1-libs and --with-boot-libs. Sets default value for --with-boot-ldflags to empty.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #10 from vries at gcc dot gnu.org --- Looking at the description of with-host-libstdcxx: ... --with-host-libstdcxx=linker-args If you are linking with a static copy of PPL, you can use this option to specify how the linker should find the standard C++ library used internally by PPL. Typical values of linker-args might be ‘-lstdc++’ or ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy of PPL, you probably do not need this option; shared library dependencies will cause the linker to search for the standard C++ library automatically. ... We no longer support building with PPL ( https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item probably needs to be updated.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #9 from vries at gcc dot gnu.org --- I've done the same build using gcc-5-branch. There, stage2 genpreds also depends on libstdc++.so.6, but no symbols from it are needed, and no version is required, so the build doesn't break.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #8 from vries at gcc dot gnu.org --- (In reply to vries from comment #7) > I start to suspect it's related to this configure bit: > ... > --with-host-libstdcxx=-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc > -Wl,-Bstatic,-lstdc++,-Bdynamic -lm > ... > full configure: ... Using built-in specs. COLLECT_GCC=./obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: src/gcc-mainline/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --disable-nls --prefix=install --with-gmp=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr --with-mpfr=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr --with-mpc=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr --with-host-libstdcxx='-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr --enable-libgomp --enable-libitm --enable-libatomic --disable-libssp --with-build-time-tools=install/x86_64-unknown-linux-gnu/bin --with-build-time-tools=install/x86_64-unknown-linux-gnu/bin SED=sed Thread model: posix gcc version 6.0.0 20150801 (experimental) (GCC) ...
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #7 from vries at gcc dot gnu.org --- (In reply to vries from comment #6) > (In reply to H.J. Lu from comment #5) > > (In reply to vries from comment #4) > > > (In reply to H.J. Lu from comment #3) > > > > Only build/genpreds in stage1 should be linked with libstdc++.so.6. > > > > > > Why? > > > > Top level configure.ac has > > > > [stage1_ldflags= > > # In stage 1, default to linking libstdc++ and libgcc statically with GCC > > # if supported. But if the user explicitly specified the libraries to use, > > # trust that they are doing what they want. > > if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then > >stage1_ldflags="-static-libstdc++ -static-libgcc" > > fi]) > > AC_SUBST(stage1_ldflags) > > > > Why doesn't it work for you? > > AFAIU, this question has the premise that something is going wrong in > stage1, which is not the case in this PR, it's about stage2. So I'm not sure > how to answer this question. OK, I think I got your point (the posted code was stage1 related, but there is similar code for poststage1). The question is why we're linking with dynamic instead of static libstdc++ in stage2. I start to suspect it's related to this configure bit: ... --with-host-libstdcxx=-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm ... This causes poststage1_libs to be set, which causes poststage1_ldflags to be empty, rather than the default "-static-libstdc++ -static-libgcc". So, on one hand, in the build/genpreds link line, we do not use poststage1_libs. OTOH, we do use poststage1_ldflags, but that's empty now.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to H.J. Lu from comment #5) > (In reply to vries from comment #4) > > (In reply to H.J. Lu from comment #3) > > > Only build/genpreds in stage1 should be linked with libstdc++.so.6. > > > > Why? > > Top level configure.ac has > > [stage1_ldflags= > # In stage 1, default to linking libstdc++ and libgcc statically with GCC > # if supported. But if the user explicitly specified the libraries to use, > # trust that they are doing what they want. > if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then >stage1_ldflags="-static-libstdc++ -static-libgcc" > fi]) > AC_SUBST(stage1_ldflags) > > Why doesn't it work for you? AFAIU, this question has the premise that something is going wrong in stage1, which is not the case in this PR, it's about stage2. So I'm not sure how to answer this question.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #5 from H.J. Lu --- (In reply to vries from comment #4) > (In reply to H.J. Lu from comment #3) > > Only build/genpreds in stage1 should be linked with libstdc++.so.6. > > Why? Top level configure.ac has [stage1_ldflags= # In stage 1, default to linking libstdc++ and libgcc statically with GCC # if supported. But if the user explicitly specified the libraries to use, # trust that they are doing what they want. if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then stage1_ldflags="-static-libstdc++ -static-libgcc" fi]) AC_SUBST(stage1_ldflags) Why doesn't it work for you?
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to H.J. Lu from comment #3) > Only build/genpreds in stage1 should be linked with libstdc++.so.6. Why? > Why are build/genpreds in stage2 and stage2 linked with libstdc++.so.6? AFAICT, the -L bits here in src/Makefile.in: ... POSTSTAGE1_CXX_EXPORT = \ CXX='$(CXX)'; export CXX; \ CXX_FOR_BUILD='$(CXX_FOR_BUILD)'; export CXX_FOR_BUILD; @if target-libstdc++-v3-bootstrap # Override the above if we're bootstrapping C++. POSTSTAGE1_CXX_EXPORT = \ CXX="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xg++$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ `if $(LEAN); then echo ' -isystem '; else echo ' -I'; fi`$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \ `if $(LEAN); then echo ' -isystem '; else echo ' -I'; fi`$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \ `if $(LEAN); then echo ' -isystem '; else echo ' -I'; fi`$$s/libstdc++-v3/libsupc++ \ -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs"; \ export CXX; \ CXX_FOR_BUILD="$$CXX"; export CXX_FOR_BUILD; @endif target-libstdc++-v3-bootstrap ...
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-02 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- Only build/genpreds in stage1 should be linked with libstdc++.so.6. Why are build/genpreds in stage2 and stage2 linked with libstdc++.so.6?
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 vries at gcc dot gnu.org changed: What|Removed |Added Summary|bootstrap failure with |bootstrap failure in |CFLAGS/CXXFLAGS/BOOT_CFLAGS |running genpreds, libstdc++ |="-O0 -g" in running|version mismatch |genpreds| --- Comment #2 from vries at gcc dot gnu.org --- Also ran into it now without setting CFLAGS. This failure is with ld 2.23.51: ... $ ld -v GNU ld (GNU Binutils) 2.23.51.20120829 ... With a different set of build scripts, another linker is used: ... $ /usr/bin/ld -v GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ... and I don't run into this problem. I once case we end up needed libstdc++ for genpreds, in the other case, not. In the case we end up needing it, we need these symbols: ... $ objdump -d -a -x obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-gcc/build/genpreds | grep GLIBCXX | c++filt 0x08922974 0x00 03 GLIBCXX_3.4 F *UND* std::basic_string, std::allocator >::c_str() const@@GLIBCXX_3.4 F *UND* operator delete(void*)@@GLIBCXX_3.4 F *UND* std::basic_string, std::allocator >::basic_string(unsigned long, char, std::allocator const&)@@GLIBCXX_3.4 F *UND* std::basic_string, std::allocator >::~basic_string()@@GLIBCXX_3.4 F *UND* std::allocator::~allocator()@@GLIBCXX_3.4 F *UND* std::allocator::allocator()@@GLIBCXX_3.4 F *UND* operator new(unsigned long)@@GLIBCXX_3.4 ... AFAICT, there are no uses of these symbols. I think that by inserting some c++ code in genpreds.c, we should be able to trigger this reliably, independent of ld version. Updating summary.
