Am 10.02.21 um 16:04 schrieb Xi Ruoyao:
On 2021-02-10 14:16 +0100, Viktor Engelmann wrote:Am 09.02.2021 um 16:46 schrieb Xi Ruoyao:On 2021-02-09 16:11 +0100, Viktor Engelmann wrote:Hello everyone,I'm building LFS 10.0 on a fully updated Manjaro Linux on an x86_64 for x86_64. When I compile M4 (chapter 6.2), I get two errors: - gcc complains about a void function ("fault_handler") being declared as "pure" in line 146 of m4.c - gcc complains about the flag -Wabi which is deprecated and doesn't do anything (see the attached log file) I was able to circumvent the problems by setting the environment variable CFLAGS=" -fpermissive -Wabi=11 " before ./configure, but I think that these are infact bugs in M4, so gcc is rightfully complaining. It seems that an older gcc version had failed if that function was NOT declared "pure" and the M4 team has also discussed this topic in july 2020, see https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=fault_handler&submit=Search%21&idxname=bug-m4&max=20&result=normal&sort=score they had also decided to make the function NOT "pure" (because fault_handler has sideeffects and should therefore not be pure). This was implemented by commit 74915227e245c2f93d0db1ff3c53544d8f594dfa in the m4 git repository, but the declaration is still present in the .tar.xz from 2016 on http://ftp.gnu.org/gnu/m4/ that is used in LFS. I verified that LFS and LFS_TGT are set and that I'm compiling with x86_64-lfs-linux-gnu-gcc. Everything before M4 was built as regular user.Those warnings should not be enabled by default. Is your M4 tarball has the same MD5 checksum in the book? Or did you use some configure options not mentioned by the book?Yes, I have compared all the MD5 sums. I followed the book very closely and I have just compared my scripts to the book again and rebuilt again. Everything else from chapter 5 and 6 worked fine. The only thing I can think of that I (might) have done differently is that I deleted the gcc-10.2.0 directory between building gcc and libstdc++. The book doesn't explicitly say whether you should do that and my script deletes target-directories before untaring to prevent conflicts with previous builds (so the gcc directory is deleted because libstdc++ is extracted to the same directory as gcc, because it comes from the same tarball)It should be deleted.In the end, the function /is/ declared as pure and that /is/ logically wrong, so it's correct of gcc to at least issue a warning. A warning is also arguable when you pass a deprecated parameter such as -Wabi. It seems that the warnings are turned into errors because -Werror is also passed somewhere - I'm still looking into where that happens. But I would argue that you should use -Werror whenever possible to avoid unwanted results as much as possible.It's too idealistic. Warnings like -Wmaybe-uninitialized produce false positives by their nature. And using -Werror in a release tarball makes a bomb which explodes if the users have a different compiler, or use some custom CFLAGS. In your build the configuration process somehow "--enable-gcc-warnings" is enabled. It's intended for developers only and should not be enabled by default in a release. Could you attach your config.log of M4 here?
I know it's too idealistic, but I'd still prefer having it when possible. config.log is attached. I've looked into it and also into configure.ac, but nothing stood out to me. I'm not so familiar with the autotools - but I guess I need to get familiar with them...
config.tar.gz
Description: application/gzip
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
