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?
--
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
