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

Reply via email to