On 2021-02-10 20:10 +0100, Viktor Engelmann wrote: > > 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... >
Hi Viktor, I spent some time try to diagnostic this issue. I can only make a guess that you should create the lfs user, and add .bashrc & .bash_profile to set up a clean environment for LFS. Some strange environment variables in host system can affect building process. (Your config.log indicates that you forgot to do this, or did this incorrectly.) -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- 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