[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #17 from Xi Ruoyao --- (In reply to Romain Geissler from comment #15) > Thanks for these remarks. > > FYI, what I am following are the Linux From Scratch guidelines, which build > the initial gcc like this (with both c and C++ support, disabling libstdc++ > build): > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html > Then after building the glibc, they do build the libstdc++ alone like this: > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++. > html > > With this PR I just found out that either my understanding of LFS is wrong, > either LFS itself is. Indeed I don't like much that when configured using my > bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to > find C headers. I will have a look to sort this out. LFS is not wrong but it's only tested with GCC-8.2, not GCC trunk. Its FAQ explicitly said "you can't gather all latest packages from ftp.gnu.org and expect them to work" :).
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #16 from joseph at codesourcery dot com --- On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote: > FYI, what I am following are the Linux From Scratch guidelines, which build > the > initial gcc like this (with both c and C++ support, disabling libstdc++ > build): > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html > Then after building the glibc, they do build the libstdc++ alone like this: > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html Those instructions use libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes with glibc, which haven't been needed since my commit e7dbb1bec3be35897acb18aa277807ed276384c5, "Weaken two NPTL configure link tests to compile tests.", March 2012. I advise looking at how glibc's build-many-glibcs.py does things for the modern approach for bootstrapping a cross-compilation toolchain for a target using glibc. (Although some pieces may need adjusting if what you want is a native toolchain using unusual directory arrangements, which some of those LFS instructions seem to suggest.)
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #15 from Romain Geissler --- Thanks for these remarks. FYI, what I am following are the Linux From Scratch guidelines, which build the initial gcc like this (with both c and C++ support, disabling libstdc++ build): http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html Then after building the glibc, they do build the libstdc++ alone like this: http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html With this PR I just found out that either my understanding of LFS is wrong, either LFS itself is. Indeed I don't like much that when configured using my bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to find C headers. I will have a look to sort this out.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #14 from joseph at codesourcery dot com --- On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote: > - binutils, with a linker configured to look for system libraries in a > non-standard folder, empty for now > - gcc, without libstdc++ The first GCC should be --enable-languages=c --disable-shared --without-headers --with-newlib (where --with-newlib means "define inhibit_libc", as required to stop libgcc from needing libc headers in some cases) - you may need various other --disable- options for other GCC libraries that can't be built without glibc headers (see the full options used in glibc's build-many-glibcs.py for a list that is sufficient). In particular, libstdc++ should not be built until glibc has been built. > - glibc, using the above binutils/gcc, which fills in the non standard lib > folder with only a libc. > - libstdc++, using the above binutils/gcc/glibc. A second GCC should be built with all languages you want, shared libraries enabled (in particular, once you've built glibc you can build a proper shared libgcc with DT_NEEDED pointing correctly to libc, which you can't until glibc has been built). It's true that ideally the host-side code in GCC would be built just once (but libgcc built twice), but that's not currently supported by the GCC build system. > Note that this is just the beginning of the bootstrap. After this other > gcc/libstdc++ are being built, and this time the configure script works > unpatched. Two GCC builds suffice with modern (c. 2012 and later; GCC 4.9 and later, glibc 2.17 and later, roughly) tools. The stripped glibc shared libraries built with the first GCC using the above process should be identical to the stripped glibc shared libraries resulting from any longer alternating series of GCC and glibc builds.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #13 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > (In reply to Romain Geissler from comment #9) > > This may be some naive question, but if we are currently trying to build a > > libstdc++, shouldn't we assume there is no pre-existing libstdc++ and run > > the different checks in the configure script either with the C compiler (if > > indeed we never use C++) > > No, because testing whether a C compiler can use those functions tells us > nothing about whether G++ will be able to use them. C libraries expose > different declarations to C and C++ programs. > > > or with CXXFLAGS like -nodefaultlib ? > > That would also make libc unavailable. The C++ configure tests are done with the newly-built xgcc, which means it won't try to link to libstdc++. In my config.log I see this command: configure:80504: checking for utime configure:80554: /tmp/build/./gcc/xgcc -shared-libgcc -B/tmp/build/./gcc -nostdinc++ -L/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include-o conftest -g -O2 -D_GNU_SOURCE -fno-exceptions -Wl,-t conftest.cpp >&5 There's no -lstdc++ there, and xgcc won't add it implicitly. The problem is that you're using x86_64-1a-linux-gnu-g++ as the compiler for these tests, and g++ automatically adds -lstdc++.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Fixed now - thanks for the report.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Tue Jan 8 10:18:54 2019 New Revision: 267705 URL: https://gcc.gnu.org/viewcvs?rev=267705&root=gcc&view=rev Log: PR libstdc++/88749 fix build failure in src/filesystem/ops.cc PR libstdc++/88749 * src/filesystem/ops.cc (last_write_time): Fix preprocessor condition to match the one that controls whether utimbuf and utime are declared. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #10 from Jonathan Wakely --- (In reply to Romain Geissler from comment #8) > So with these explanations, do you think the patch you proposed should land > in trunk (it worked for me in that specific bootstrap configuration). Yes the patch is correct regardless and I'll commit it shortly. The explanation also makes sense of the results too. (In reply to Romain Geissler from comment #9) > This may be some naive question, but if we are currently trying to build a > libstdc++, shouldn't we assume there is no pre-existing libstdc++ and run > the different checks in the configure script either with the C compiler (if > indeed we never use C++) No, because testing whether a C compiler can use those functions tells us nothing about whether G++ will be able to use them. C libraries expose different declarations to C and C++ programs. > or with CXXFLAGS like -nodefaultlib ? That would also make libc unavailable.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #9 from Romain Geissler --- This may be some naive question, but if we are currently trying to build a libstdc++, shouldn't we assume there is no pre-existing libstdc++ and run the different checks in the configure script either with the C compiler (if indeed we never use C++) or with CXXFLAGS like -nodefaultlib ?
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #8 from Romain Geissler --- Your patch is working. I may add some context to better understand this strange scenario. In my case, the config log says: configure:80434: checking for utimensat configure:80484: x86_64-1a-linux-gnu-g++ -o conftest -O2 -mmmx -msse -msse2 -msse3 -fno-exceptions -O2 -mmmx -msse -msse2 -msse3 conftest.cpp >&5 /home/jenkins/workspace/OTF_Toolchain_release_20.0-GWCRYYLPVAZ3GI64ZF43J2FVALYHUCNKGFBXVRTH6NJF73DCK7SQ/output/build/temporary-system/install/bin/../lib/gcc/x86_64-1a-linux-gnu/9.0.0/../../../../x86_64-1a-linux-gnu/bin/ld: cannot find -lstdc++ for all find of header check, so in the end they all end up being as not found. I don't just build gcc or libstdc++ in my build, actually it's a full toolchain bootstrap following what is done in Linux From Scratch. I build in that order: - binutils, with a linker configured to look for system libraries in a non-standard folder, empty for now - gcc, without libstdc++ - glibc, using the above binutils/gcc, which fills in the non standard lib folder with only a libc. - libstdc++, using the above binutils/gcc/glibc. At the moment we build this first libstdc++, there is no existing libstdc++ yet, thus the above configure failures. Note that this is just the beginning of the bootstrap. After this other gcc/libstdc++ are being built, and this time the configure script works unpatched. So with these explanations, do you think the patch you proposed should land in trunk (it worked for me in that specific bootstrap configuration).
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #7 from Jonathan Wakely --- What does your $target/libstdc++-v3/config.log show for the utime tests? With glibc-2.28 I get: configure:80229: checking for utime.h configure:80229: result: yes configure:80254: checking whether to build Filesystem TS support configure:80278: result: yes configure:80292: checking for struct dirent.d_type configure:80352: result: yes configure:80354: checking for realpath configure:80432: result: yes configure:80434: checking for utimensat configure:80500: result: yes configure:80502: checking for utime configure:80566: result: yes
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #5 from Romain Geissler --- Note that it was building fine with gcc commit 4a4bec8257aa255cca9be7f24a61159cadb36942 from Fri Dec 28 (aka r267451), and the same glibc commit.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #6 from Jonathan Wakely --- That makes no sense, because you should have _GLIBCXX_USE_UTIMENSAT defined and never reach the lines that give errors.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 --- Comment #4 from Romain Geissler --- Thanks I will test this ASAP. I am using x86-64, and a very recent glibc near current master: GLIBC_VERSION="2.28.90" GLIBC_COMMIT="0253580a75decdaf22b6abce60d8265b2adb7dea"
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #3 from Jonathan Wakely ---
I don't understand why the configure script would not have set
_GLIBCXX_USE_UTIME when utimbuf and utime() are apparently available (because
GCC is suggesting them as alternatives for posix::utimbuf and posix::utime).
I think this should fix it, but as Andrew requested, please provide a lot more
information about your target:
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -909,7 +909,7 @@ fs::last_write_time(const path& p
__attribute__((__unused__)),
ec.assign(errno, std::generic_category());
else
ec.clear();
-#elif _GLIBCXX_HAVE_UTIME_H
+#elif _GLIBCXX_USE_UTIME && _GLIBCXX_HAVE_SYS_STAT_H
posix::utimbuf times;
times.modtime = s.count();
times.actime = do_stat(p, ec, [](const auto& st) { return st.st_atime; },
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-07 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|Failure while building |[9 Regression] Failure |libstdc++-v3/src/filesystem |while building |/ops.cc on trunk|libstdc++-v3/src/filesystem ||/ops.cc on trunk Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I added _GLIBCXX_USE_UTIME to be used instead of _GLIBCXX_HAVE_UTIME_H but only changed one of the two places that should use it.
