Re: [lfs-support] Problem compiling findutils

2019-08-02 Thread Michael Shell 
On Fri, 2 Aug 2019 23:36:36 -0500
Bruce Dubbs  wrote:

> 4.6.0 does build against the latest glibc with:
> 
> sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' gl/lib/*.c
> sed -i '/unistd/a #include ' gl/lib/mountlist.c
> echo "#define _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h


Yeah, *we* LFS folks can fix it ourselves with such, but we want upstream
to do a new release and so its helpful to bring up any point that can
help out in that regard. ;)


  Mike

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

Re: [lfs-support] Problem compiling findutils

2019-08-02 Thread Bruce Dubbs 

On 8/2/19 10:10 PM, Michael Shell wrote:

On Fri, 2 Aug 2019 10:49:07 -0500
Bruce Dubbs  wrote:


A new version should simplify our instructions. My inclination is to
create our own tarball from git.


I found this from a year ago on the findutils mailing list:

https://lists.gnu.org/archive/html/bug-findutils/2018-08/msg8.html

So, they do intend to have a release. Maybe one of us could ask
them again on the findutils mailing list, making sure to point out
that 4.6.0 won't build against the latest glibc.


4.6.0 does build against the latest glibc with:

sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' gl/lib/*.c
sed -i '/unistd/a #include ' gl/lib/mountlist.c
echo "#define _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h

but a new version would still be nice.  I was able to create a tarball 
that we could use.  I'm undecided about whether to use it.


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

Re: [lfs-support] Problem compiling findutils

2019-08-02 Thread Michael Shell 
On Fri, 2 Aug 2019 10:49:07 -0500
Bruce Dubbs  wrote:

> A new version should simplify our instructions. My inclination is to 
> create our own tarball from git.

I found this from a year ago on the findutils mailing list:

https://lists.gnu.org/archive/html/bug-findutils/2018-08/msg8.html

So, they do intend to have a release. Maybe one of us could ask
them again on the findutils mailing list, making sure to point out
that 4.6.0 won't build against the latest glibc.


  Mike



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

Re: [lfs-support] Problem compiling findutils

2019-08-02 Thread Bruce Dubbs 

On 8/1/19 11:08 PM, Michael Shell wrote:

On Wed, 31 Jul 2019 20:47:30 +
Niels Terp  wrote:


fflush.c:42:20: error: '_IO_IN_BACKUP' undeclared (first use in this function)


This command in the instructions was missed:

echo "#define _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h



FWIW, IMHO, GNU really needs to release a newer version of findutils.
The latest release dates to 2015

https://ftp.gnu.org/pub/gnu/findutils/

and won't compile with the latest glibc, which is the problem you are seeing.
That issue, and many, many more have already been fixed in the findutils
git tree:

https://savannah.gnu.org/git/?group=findutils
https://git.savannah.gnu.org/cgit/findutils.git/

Just look at all the stuff the git version of findutils fixes:

https://git.savannah.gnu.org/cgit/findutils.git/log/

It takes 5 pages of these fixes to reach back to the 4.6.0 release
point. Look at all the bugs that have been fixed since then. Wow!

Remember that when building from git source, you may have to run

autoreconf

first to get a working ./configure script.

Alternatively, debian's findutils source package is based on the git
tree back in May:

https://packages.debian.org/sid/findutils
http://deb.debian.org/debian/pool/main/f/findutils/findutils_4.6.0+git+20190510-2.debian.tar.xz

Maybe we at LFS should consider switching to building findutils
from GIT (or providing our own GIT snapshot release) or use the
debian source package until GNU does another release.


We are going into package freeze in about two weeks for the next LFS 
release.  I'll look at this closely just before freeze.  I created a 
ticket so we will not forget.


A new version should simplify our instructions. My inclination is to 
create our own tarball from git.


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

Re: [lfs-support] Problem compiling findutils

2019-08-01 Thread Michael Shell 
On Wed, 31 Jul 2019 20:47:30 +
Niels Terp  wrote:

> fflush.c:42:20: error: '_IO_IN_BACKUP' undeclared (first use in this function)


FWIW, IMHO, GNU really needs to release a newer version of findutils.
The latest release dates to 2015

https://ftp.gnu.org/pub/gnu/findutils/

and won't compile with the latest glibc, which is the problem you are seeing.
That issue, and many, many more have already been fixed in the findutils
git tree:

https://savannah.gnu.org/git/?group=findutils
https://git.savannah.gnu.org/cgit/findutils.git/

Just look at all the stuff the git version of findutils fixes:

https://git.savannah.gnu.org/cgit/findutils.git/log/

It takes 5 pages of these fixes to reach back to the 4.6.0 release
point. Look at all the bugs that have been fixed since then. Wow!

Remember that when building from git source, you may have to run

autoreconf

first to get a working ./configure script.

Alternatively, debian's findutils source package is based on the git
tree back in May:

https://packages.debian.org/sid/findutils
http://deb.debian.org/debian/pool/main/f/findutils/findutils_4.6.0+git+20190510-2.debian.tar.xz

Maybe we at LFS should consider switching to building findutils
from GIT (or providing our own GIT snapshot release) or use the
debian source package until GNU does another release.


  Cheers,

  Mike Shell


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

Re: [lfs-support] Problem compiling findutils

2019-07-31 Thread Ken Moffat 
On Wed, Jul 31, 2019 at 08:47:30PM +, Niels Terp wrote:
> Hi there,
> 
> 
> 
> Following the current lfs, during building I run into a problem with 
> findutils: During MAKE, I get this error:
> 
> 
> 
> fflush.c: In function 'clear_ungetc_buffer_preserving_position':
> 
> fflush.c:42:20: error: '_IO_IN_BACKUP' undeclared (first use in this function)
> 
>if (fp->_flags & _IO_IN_BACKUP)
> 
> ^
> 
> fflush.c:42:20: note: each undeclared identifier is reported only once for 
> each function it appears in
> 
> Makefile:2225: recipe for target 'fflush.o' failed
> 
> make[5]: *** [fflush.o] Error 1
> 
> make[5]: *** Waiting for unfinished jobs
> 
> make[5]: Leaving directory 
> '/mnt/lfs/usr/src/Octothorpe/BUILD/findutils-4.6.0/gl/lib'
> 
> 
> 
> Seems related to the last command before configure: echo "#define 
> _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h
> 
> And sure enough, if I comment this line out, the MAKE finishes (apparently) 
> successful, but the ”find” command does not Work.
> 
> 
> 
> Can anybody give me a hint ?
> 
> 
> 
> Best regards
> 
> 
> 
> Niels
> 

Nils, please start new threads rather than replying to (and top
posting on) somebody else's old thread.  And your mailer seems to
make a fetish of adding unuseful whitespace.

Anyway, given that you included someone's reply about an 8.4 build,
I assume that 'current' means 8.4 (rather than svn).

That change was made in August last year and included in LFS-8.3.
To quote https://github.com/coreutils/gnulib/blob/master/lib/stdio-impl.h
(line 21) :

/* Glibc 2.28 made _IO_IN_BACKUP private.  For now, work around this
   problem by defining it ourselves.  FIXME: Do not rely on glibc
   internals.  */

So this is by no means a recent change.  The error message perhaps
means that your echo of the #define somehow did not work.  But in
that case, building without the #define would also result in an
error.  I think you must be doing something different from what is
in the book, but I have no idea what.

So, all I can suggest is that you confirm you are using the same
versions of everything as in the book, and that you review your bash
history in chroot to see what you actually typed (or your scripts,
if you are scripting) and compare that to the book.

And if this is actually the svn book, please make a local copy of it
because it can change underneath you if you are reading the current
html and building one package at a time.

ĸen
-- 
One pill makes you larger, And one pill makes you small.
And the ones that mother gives you, Don't do anything at all.
Go ask Alice, When she's ten feet tall.
   -- Jefferson Airplane, White Rabbit
-- 
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

[lfs-support] Problem compiling findutils

2019-07-31 Thread Niels Terp 
Hi there,



Following the current lfs, during building I run into a problem with findutils: 
During MAKE, I get this error:



fflush.c: In function 'clear_ungetc_buffer_preserving_position':

fflush.c:42:20: error: '_IO_IN_BACKUP' undeclared (first use in this function)

   if (fp->_flags & _IO_IN_BACKUP)

^

fflush.c:42:20: note: each undeclared identifier is reported only once for each 
function it appears in

Makefile:2225: recipe for target 'fflush.o' failed

make[5]: *** [fflush.o] Error 1

make[5]: *** Waiting for unfinished jobs

make[5]: Leaving directory 
'/mnt/lfs/usr/src/Octothorpe/BUILD/findutils-4.6.0/gl/lib'



Seems related to the last command before configure: echo "#define _IO_IN_BACKUP 
0x100" >> gl/lib/stdio-impl.h

And sure enough, if I comment this line out, the MAKE finishes (apparently) 
successful, but the ”find” command does not Work.



Can anybody give me a hint ?



Best regards



Niels



Sendt fra Mail til Windows 10




Fra: lfs-support  på vegne af 
Douglas R. Reno 
Sendt: Wednesday, May 29, 2019 4:02:01 PM
Til: LFS Support List 
Cc: Vineet Jain 
Emne: Re: [lfs-support] Stalled on LFS 8.4 Section 6.7 - None of the 
executables can be found

On 2019-05-29 06:32, Vineet Jain wrote:
> Hello,
>
> I am building LFS from version 8.4 and run into issues in actually
> building of the LFS System.
> For me the Part II that is Preparing the host system seems to have
> been completed successfully but the actual construction of LFS is
> failing.
>
> On trying to execute MAKE MRPROPER from the linux-4.20.12 folder
> it gives me the error
> /bin/sh: sed: command not found
> Makefile:624: arch//Makefile: No such file or directory
> make: *** No rule to make target 'arch//Makefile'.  Stop.
>
> In fact other executables like tar, files also cannot be executed.
>
> _Host sys being used is_
> Ubuntu 18.04.2 LTS
>
> _Version Check output_
> Binutils for Ubuntu) 2.30
> bison (GNU Bison) 3.0.4
> /usr/bin/yacc -> /usr/bin/bison.yacc
> bzip2,  Version 1.0.6, 6-Sept-2010.
> Coreutils:  8.28
> diff (GNU diffutils) 3.6
> find (GNU findutils) 4.7.0-git
> GNU Awk 4.1.4, API: 1.1 (GNU MPFR 4.0.1, GNU MP 6.1.2)
> /usr/bin/awk -> /usr/bin/gawk
> gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
> g++ (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
> (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
> grep (GNU grep) 3.1
> gzip 1.6
> Linux version 5.0.5-050005-generic (kernel@tangerine) (gcc version
> 8.3.0 (Ubuntu 8.3.0-3ubuntu1)) #201903271212 SMP Wed Mar 27 16:14:07
> UTC 2019
> m4 (GNU M4) 1.4.18
> GNU Make 4.1
> Perl version='5.26.1';
> Python 3.6.7
> sed (GNU sed) 4.4
> tar (GNU tar) 1.29
> texi2any (GNU texinfo) 6.5
> xz (XZ Utils) 5.2.2
> g++ compilation OK
>

Your host system and requirements look OK.

> The deviation from the book is
> - did not delete the individual source folders after installation

This is a big problem. You'll need to restart from Chapter 5, and make
sure that you remove source directories. That leads to contamination,
because you might build with the wrong compiler - or when you get to
Chapter 6, end up with problems like you've shown.

> - did not compare the installations logs with the ones published on
> the site so not certain if the installation of all temporary
> components did go through correctly or not.
>

That's really unnecessary, I only recommend reviewing the logs if you're
seeing weird test failures.

> Am I missing a setting that needs to be done or do I need to
> re-prepare the host system and start all over again ?
>

You'll need to start over, unfortunately. Make sure that you delete the
individual source folders after installation.

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