Re: [lfs-dev] Promote JS78.8.0 for 10.1 ?

[Pierre Labastie via lfs-dev]

On Wed, 2021-02-24 at 02:02 +, Ken Moffat via lfs-dev wrote:
> I see that people have been busy tagging things whilst I've been
> offline.  One of those things is JS-78.8.0.
> 
> Technically, the JS build does not appear to contain any security
> fixes, just one or two lines of python got changed.  But
> firefox-78.8.0 does contain the usual crop of fixes rated as 'high'.
> 
> Firefox has not yet been tagged, so no problem.
> 
> I'd like to promote JS-78.8.0 for 10.1 so that we continue to use
> the same version of the tarball.  Although I have not yet built this
> version of firefox on 10.1, I have built and measured on a system
> from 6th February with various later updates, and I've now got JS
> 78.8.0 running on two machines which have not yet got as far as
> firefox.

FWIIW, js78 is a dependency of:
- polkit: tagged
- gjs: not tagged yet

According to Xi Ruoyao, nothing dependent on polkit uses js. I'd say we
need to test gjs (not tagged yet), and its dependencies (g-ir
(optional), gnome-shell, libsecret (optional), gnome-maps, and gnome-
weather)

Pierre




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Possible binutils-2.36 problems

[Pierre Labastie via lfs-dev]

On Mon, 2021-02-08 at 19:36 +0100, Pierre Labastie via lfs-dev wrote:
> On Fri, 2021-02-05 at 17:40 +, Ken Moffat via lfs-dev wrote:
> > On Fri, Feb 05, 2021 at 10:39:08AM -0600, Bruce Dubbs via lfs-dev
> > wrote:
> > > On 2/5/21 6:48 AM, Ken Moffat via lfs-dev wrote:
> > > > While replying to Frans on -support re his inability to build
> > > > glibc-2.33, I glanced at the binutils bugs
> > > > https://www.mail-archive.com/bug-binutils@gnu.org/ and said
> > > > that
> > > > 2.36 might be buggy.  At that time I hadn't read all the links
> > > > gurgle found for me.  One of them is
> > > > https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/
> > > > which looks *really* annoying.
> > > 
> > > I took a look at the above link, but I cannot reproduce the
> > > problem
> > > with LFS
> > > instructions.  In my test build in /mnt/lfs/lib I have:
> > > 
> > > 
> > > [ /mnt/lfs/lib ]$ ll libc*
> > > lrwxrwxrwx 1 root root   14 Feb  2 16:20 libcap.so.2 ->
> > > libcap.so.2.47
> > > -rwxr-xr-x 1 root root    39440 Feb  2 17:44 libcap.so.2.47
> > > lrwxrwxrwx 1 root root   17 Feb  2 17:44 libcom_err.so.2 ->
> > > libcom_err.so.2.1
> > > -rwxr-xr-x 1 root root    18776 Feb  2 17:44 libcom_err.so.2.1
> > > -rwxr-xr-x 1 root root    43288 Feb  2 17:44 libcrypt-2.33.so
> > > lrwxrwxrwx 1 root root   16 Feb  2 16:10 libcrypt.so.1 ->
> > > libcrypt-2.33.so
> > > -rwxr-xr-x 1 root root  1835448 Feb  2 17:44 libc-2.33.so
> > > -rwxrwxr-x 1 root root 11946280 Feb  2 17:44 libc-2.33.so.dbg
> > > lrwxrwxrwx 1 root root   12 Feb  2 16:10 libc.so.6 -> libc-
> > > 2.33.so
> > > 
> > > [ /mnt/lfs/lib ]$ file libc-2.33.so
> > > libc-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1
> > > (GNU/Linux),
> > > dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for
> > > GNU/Linux
> > > 3.2.0, stripped
> > > 
> > > [ /mnt/lfs/lib ]$ file libcap.so.2.47
> > > libcap.so.2.47: ELF 64-bit LSB shared object, x86-64, version 1
> > > (SYSV),
> > > dynamically linked, stripped
> > > 
> > > So the book does what we want.  On the other hand, we do not do
> > > an
> > > unconditional strip on anything.  We start with find /lib
> > > /usr/lib
> > > -type f
> > > -name \*.so* ...  so that would skip symlinks.
> > > 
> > > We use the same structure in BLFS Section "Notes on Building
> > > Software".
> > > 
> > > On the other hand, doing an explicit strip on a symlink does
> > > replace the
> > > symlink with the stripped version of the link's resolved file.
> > > 
> > > I can confirm that running strip against a symlink on a system
> > > with
> > > binutils-2,25 does not affect the symlink.
> > > 
> > >   -- Bruce
> > > 
> > Hi Bruce,
> > 
> > thanks for looking at this. At the moment I don't have 2.36, I'm
> > just warning that some people are reporting enough
> > changed/unexpected behaviour that this might cause problems.
> > 
> > good to know that we are not directly affected by the stripping
> > change.
> > 
> 
> Huh, As I read above "doing an explicit strip on a symlink does
> replace the symlink with the stripped version of the link's resolved
> file", while for 2.35:
> "binutils-2,25 does not affect the symlink" (guess Bruce meant 2.35)
> 
> Another report of a similar problem (maybe more annoying):
> https://bugs.archlinux.org/task/69584
> 
> strip seems to change the ownership of a file to that of the user
> running strip.
> 
> Also (maybe a fakeroot problem):
> https://sourceware.org/pipermail/binutils/2021-February/115241.html
> 

The issue with ownership seems to be a fakeroot problem (when compiled
with glibc-2.33 and binutils-2.36), sorry for the noise.

And the book itself is immune to the symlink problem since we use "find
-type f". Looks like upstream has fixed some CVE by changing the
behavior, so we'll have to live with it.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Possible binutils-2.36 problems

[Pierre Labastie via lfs-dev]

On Fri, 2021-02-05 at 17:40 +, Ken Moffat via lfs-dev wrote:
> On Fri, Feb 05, 2021 at 10:39:08AM -0600, Bruce Dubbs via lfs-dev
> wrote:
> > On 2/5/21 6:48 AM, Ken Moffat via lfs-dev wrote:
> > > While replying to Frans on -support re his inability to build
> > > glibc-2.33, I glanced at the binutils bugs
> > > https://www.mail-archive.com/bug-binutils@gnu.org/ and said that
> > > 2.36 might be buggy.  At that time I hadn't read all the links
> > > gurgle found for me.  One of them is
> > > https://www.linuxquestions.org/questions/linux-from-scratch-13/binutils-2-36-strip-4175689760/
> > > which looks *really* annoying.
> > 
> > I took a look at the above link, but I cannot reproduce the problem
> > with LFS
> > instructions.  In my test build in /mnt/lfs/lib I have:
> > 
> > 
> > [ /mnt/lfs/lib ]$ ll libc*
> > lrwxrwxrwx 1 root root   14 Feb  2 16:20 libcap.so.2 ->
> > libcap.so.2.47
> > -rwxr-xr-x 1 root root    39440 Feb  2 17:44 libcap.so.2.47
> > lrwxrwxrwx 1 root root   17 Feb  2 17:44 libcom_err.so.2 ->
> > libcom_err.so.2.1
> > -rwxr-xr-x 1 root root    18776 Feb  2 17:44 libcom_err.so.2.1
> > -rwxr-xr-x 1 root root    43288 Feb  2 17:44 libcrypt-2.33.so
> > lrwxrwxrwx 1 root root   16 Feb  2 16:10 libcrypt.so.1 ->
> > libcrypt-2.33.so
> > -rwxr-xr-x 1 root root  1835448 Feb  2 17:44 libc-2.33.so
> > -rwxrwxr-x 1 root root 11946280 Feb  2 17:44 libc-2.33.so.dbg
> > lrwxrwxrwx 1 root root   12 Feb  2 16:10 libc.so.6 -> libc-
> > 2.33.so
> > 
> > [ /mnt/lfs/lib ]$ file libc-2.33.so
> > libc-2.33.so: ELF 64-bit LSB shared object, x86-64, version 1
> > (GNU/Linux),
> > dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for
> > GNU/Linux
> > 3.2.0, stripped
> > 
> > [ /mnt/lfs/lib ]$ file libcap.so.2.47
> > libcap.so.2.47: ELF 64-bit LSB shared object, x86-64, version 1
> > (SYSV),
> > dynamically linked, stripped
> > 
> > So the book does what we want.  On the other hand, we do not do an
> > unconditional strip on anything.  We start with find /lib /usr/lib
> > -type f
> > -name \*.so* ...  so that would skip symlinks.
> > 
> > We use the same structure in BLFS Section "Notes on Building
> > Software".
> > 
> > On the other hand, doing an explicit strip on a symlink does
> > replace the
> > symlink with the stripped version of the link's resolved file.
> > 
> > I can confirm that running strip against a symlink on a system with
> > binutils-2,25 does not affect the symlink.
> > 
> >   -- Bruce
> > 
> Hi Bruce,
> 
> thanks for looking at this. At the moment I don't have 2.36, I'm
> just warning that some people are reporting enough
> changed/unexpected behaviour that this might cause problems.
> 
> good to know that we are not directly affected by the stripping
> change.
> 

Huh, As I read above "doing an explicit strip on a symlink does
replace the symlink with the stripped version of the link's resolved
file", while for 2.35:
"binutils-2,25 does not affect the symlink" (guess Bruce meant 2.35)

Another report of a similar problem (maybe more annoying):
https://bugs.archlinux.org/task/69584

strip seems to change the ownership of a file to that of the user
running strip.

Also (maybe a fakeroot problem):
https://sourceware.org/pipermail/binutils/2021-February/115241.html

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] SVN 2021-02-02

[Pierre Labastie via lfs-dev]

On Wed, 2021-02-03 at 11:56 +, Roger via lfs-dev wrote:
> At the end of section 8.7.1 installation of bzip2 is:
> 
>   rm -fv /usr/lib/libz.a
> 
> Shouldn't that be:
> 
>   rm -fv /usr/lib/libbz2.a
> -- 
> Roger
> 

This should be fixed at r12123
Thanks for the report anyway

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] LFS 10.0 read-only file system failure

[Pierre Labastie via lfs-dev]

On Wed, 2021-01-13 at 10:05 -0300, Jamenson Espindula via lfs-dev
wrote:
> Hi, everyone. Have an excellent 2021!
> 
> I just finished building the LFS 10.0. This error message was shown
> when I booted:
> 
>  = = = = = Begin of transcription = = = = =
> 
> FAILURE:
> 
> You should not be reading this error message.
> 
> It means that an unforeseen error took place in
> /etc/rc.d/rcS.d/S00mountvirtfs,
> which exited with a return value of 1.
> If you're able to track this error down to a bug in one of
> the file provided by the LFS book,
> please be so kind to inform us at lfs-...@linuxfromscratch.org
> (Registration required).
> 
>  = = = = = End of transcription = = = = =
> 
> Any idea? Kernel misconfiguration?


Looks like you haven't send the whole story. You should have seen
something like:
Mounting virtual file systems: /run /proc /sys /dev

+ maybe an error message before "FAILURE ..."

The mail subject tells "read-only file system failure", but there is no
evidence in the error message you sent us...

You should also send more information about the
disk/partition/filesystem/whatever you use for your lfs ...

Also make sure /etc/fstab is written correctly (see 10.2 Vreating the
:etc:fstab File): the lines containing /proc, /sys, /dev, /dev/pts, and
/run are _needed_ for this bootscript to run...

Regards
Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] blfs-book-10.0-html.tar.xz and lxqt

[Pierre Labastie via lfs-dev]

On Sun, 2020-12-13 at 08:40 +1100, scsijon via lfs-dev wrote:
> 
> On 13/12/20 7:00 am,
> lfs-dev-requ...@lists.linuxfromscratch.org wrote:
> Date: Fri, 11 Dec 2020 23:40:48 -0600
> > From: Bruce Dubbs 
> > To: lfs-dev@lists.linuxfromscratch.org
> > Subject: Re: [lfs-dev] blfs-book-10.0-html.tar.xz and lxqt
> > Message-ID: <2b43f379-3580-7eae-4d65-0fb27eb8b...@gmail.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> > 
> > On 12/11/20 10:55 PM, scsijon via lfs-dev wrote:
> > > Sorry folks, but downloading this file from your site gives me a
> > > corrupted file with a not-supported attributes. I've tried it a
> > > number
> > > of times with the same result. The NOCHUNKS version however seems
> > > to be ok.
> > There was a typo in the script that generated that file.  I've
> > fixed the
> > script and the tarball so you should download it again.
> 
> 
> I have and it now opens, thank you
> 
> > 
> > > My intent is to use this as the basis of a LXQT build using the
> > > LXQT
> > > section from 8.2 as a base and then use that as a stepping stone
> > > to
> > > musl/clang/llvm.
> > You know, I think, that we removed lxqt a few versions ago.
> 
> 
> Yup, 8.2 had the last one I can find, which is why I have both 
> downloaded, I suspect I may have to 'play' with the lxqt part, but as
> lxqt has evolved since then and I need that I'm going to have fun
> mixing 
> and matching to get something stable to proceed with.
> 
> > 
> > Thanks for the report.
> > 
> >     -- Bruce
> 
> And thanks as always for the quick response and fix.


If you plan to only build the needed parts of Qt library (as advised at
the beginning of the LXQt chapter), recent versions of libkscreen now
depend on kwayland, which itself depends on qtwayland, and plasma-
wayland-protocols.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Issue with GCC after leaving Chroot at end of Chap7 and re-entering it for Chap8

[Pierre Labastie via lfs-dev]

On Tue, 2020-11-17 at 15:45 +0800, Kevin Buckley via lfs-dev wrote:
> On Mon, 16 Nov 2020 at 14:49, Kevin Buckley <
> kevin.m.buck...@gmail.com> wrote:
> > 
> > Pretty sure this will be an "end-user" issue but, just in case
> > anyone
> > has seen something similar and can thus point me in the right
> > direction,
> > I have seen this twice now, and i was more careful the second time.
> > 
> > (Note: following the Multilib Book, plus some PkgUser additons)
> > 
> > Get to the end of Chapter 7
> > 
> > Run test compile and readelf interrogations for all three "arch-s"
> > so
> > 
> > gcc dummy.c
> > gcc -m32 dummy.c
> > gcc -mx32 dummy.c
> > 
> > Deep joy.
> > 
> > Exit chroot and umount bind mouted FSes
> > 
> > Backup temporary system
> > 
> > Remount bind mouted FSes
> > 
> > Re-enter chroot
> > 
> > Try to perform a simple
> > 
> > gcc dummy.c
> > 
> > Deep sorrow!
> > 
> > 
> > Output from the failed compilation suggest that there's a crtN.o
> > file, with a GlibC version that has come from the host, being
> > pulled in.
> 
> Thought I'd chuck in the actual error message in case it rings any
> bells
> for anyone.
> 
> GNU C17 (GCC) version 10.2.0 (x86_64-lfs-linux-gnu)
>     compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR
> version 4.1.0,
>  MPC version 1.2.0, isl version isl-0.22.1-GMP
> 
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
> heapsize=131072
> Compiler executable checksum: d384610cfa11eec261f14798a7f678e4
> COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/bin/a
> s -v --64 -o /tmp/cc6W4Vah.o /tmp/ccvqsYQf.s
> GNU assembler version 2.35 (x86_64-lfs-linux-gnu) using BFD version
> (GNU Binutil
> s) 2.35
> COMPILER_PATH=/usr/libexec/gcc/x86_64-lfs-linux-
> gnu/10.2.0/:/usr/libexec/gcc/x86
> _64-lfs-linux-gnu/10.2.0/:
>  /usr/libexec/gcc/x86_64-lfs-linux-gnu/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/bin/
> LIBRARY_PATH=/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/lib/../lib/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/:
>  /lib/../lib/:
>  /usr/lib/../lib/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/lib/:
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../:/lib/:
>  /usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
>  /usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/collect2 -plugin
> /usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/liblto_plugin.so
>  -plugin-opt=/usr/libexec/gcc/x86_64-lfs-linux-gnu/10.2.0/lto-wrapper
> -plugin-opt=-fresolution=/tmp/cctzwl1f.res
>  -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
>  -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64
> -dynamic-linker /lib64/ld-linux-x86-64.so.2
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crt1.o
> /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crti.o
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtbegin.o
> -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0
>  -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/lib/../lib
>  -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib -
> L/lib/../lib
>  -L/usr/lib/../lib
> -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/lib
>  -L/usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../.. /tmp/cc6W4Vah.o
> -lgcc --push-state --as-needed -lgcc_s --pop-state
>  -lc -lgcc --push-state --as-needed -lgcc_s --pop-state
> /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/crtend.o
>  /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crtn.o
> /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../x86_64-lfs-
> linux-gnu/bin/ld:
>  /usr/lib/gcc/x86_64-lfs-linux-
> gnu/10.2.0/../../../../lib/crt1.o(.text+0x26):
>  unresolvable R_X86_64_NONE relocation against symbol
> `__libc_start_main@@GLIBC_2.2.5'
> collect2: error: ld returned 1 exit status

Yes, I've seen this. It had something to do with stripping (so 1st
question is: did you strip binaries? Old versions (don't ask the
version, something around 2.28 IIRC) of strip do not recognize some 
R_X86_64_xxx relocation items and replace them with R_X86_64_NONE,
which makes the symbol undefined...

The cure is to use $LFS/usr/bin/strip for stripping. I'd say we should
put that in the instructions, actually, or change binutils requirement
to the first version which works.

> 
> (lfs chroot) root:/# file
> /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crt1.o
> /usr/lib/gcc/x86_64-lfs-linux-gnu/10.2.0/../../../../lib/crt1.o: ELF
> 64-bit LSB relocatable, x86-64, version 1 (SYSV), for GNU/Linux
> 3.2.0,
> not stripped
> 
> 
> It's the "mismatch" between GLIBC_2.2.5 that's the mystery to me.

The problem 

Re: [lfs-dev] IANA-ETC protocols/services file problems

[Pierre Labastie via lfs-dev]

On Sat, 2020-11-14 at 23:58 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-11-14 07:38 -0800, Joel Bion via lfs-dev wrote:
> > I also am using the tagged-as-a-release 20201110
> > 
> > It turns out that this is the difference: if you grab the tar file
> > from 
> > the line that says "source code (tar.gz)" you get a package without
> > the 
> > services/protocols files, and the need to run update.py. If you
> > grab the 
> > tar file from the line that says iana-etc-20201110.tar.gz - then
> > you get 
> > the pre-built protocols and services file.
> > 
> > Are these files typically DIFFERENT? I've not seen that before.
> 
> Yes they are typically different.  "source code (tar.gz)" is
> automatically
> created by GitHub so there will be no generated files (which should
> not be
> version controled) in it.

"source code" actually is a snapshot of the repository, and as said
above is automatically generated by github when tagging.
whatever.xxx.yy (usually package-version.tar.[gx]z) is whatever has
been uploaded by the owner when creating the release... Those files can
be _completely_ different.

Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] IANA-ETC protocols/services file problems

[Pierre Labastie via lfs-dev]

On Sat, 2020-11-14 at 06:18 -0800, Joel Bion via lfs-dev wrote:
> There's a bit of a mess with protocols/services in the latest builds 
> from IANA-ETC.
> 
> 1) They require that Python-3 be installed, because you need to
> generate 
> these files in these latest releases by running a script 'update.py',
> instead of just being given them in the release.
> 
> 2) The Python-3 script has a bug in the use of an obsolete method
> name 
> that needs fixing.
> 
> 3) The generated services/protocols files are set to permission 600 
> instead of the proper 644 - which is really annoying, because if
> these 
> permissions are retained (such as in an original copy to /etc, where
> the 
> files do not previously exist) - then programs that are not run as
> root 
> cannot read these files, which means that they get weird errors such
> as 
> 'unknown protocol tcp' or 'unknown service this-or-that'. Determining
> that the cause of these errors are too-strict permissions on the 
> protocols and services file is not the easiest thing in the world to
> do.
> 
> Net-net, here is the little script I wrote to handle this situation:
> 
> sed -i 's?getiterator?iter?g' update.py
> python3 update.py out
> cp -v out/dist/{protocols,services} /etc
> chmod -v u+w,a+r /etc/{protocols,services}
> ls -l /etc/{protocols,services}
> 
> -Joel

Not sure what you are talking about. I've downloaded the latest release
iana-etc-20201110.tar.gz, and the services and protocols files are
present.
It seems that there is a tag 20201019, which only contains the .xml
files and update.py. But this one is not said to be a release.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib Chapter 5 zlib: configure maybe missing --host flag

[Pierre Labastie via lfs-dev]

On Sat, 2020-11-14 at 10:45 +0800, Kevin Buckley via lfs-dev wrote:
> On Fri, 13 Nov 2020 at 09:29, Kevin Buckley
>  wrote:
> > 
> > Hi Thomas,
> > 
> > I believe that, as of Revision: 12059, your Zlib section in Chapter
> > 5
> > is missing the "--host=$LFS_TGT" flag
> > 
> > Compare
> > 
> >     Prepare Zlib for compilation:
> > 
> > ./configure
> > --prefix=/usr
> > 
> >     Compile the package:
> > 
> > 
> > with the corresponding XML from the GZip section
> > 
> > 
> >     Prepare Gzip for compilation:
> > 
> > ./configure --prefix=/usr
> > --host=$LFS_TGT
> > 
> >     Compile the package:
> > 
> > 
> > When I came to build the Zlib, I ended up getting an error from the
> > host compiler
> > and it took me a while to work out why the build wasn't using the
> > compiler in
> > $LFS/tools/bin.
> > 
> > It is also possible that the 32-bit and x32 build instructions for
> > Zlib are missing the
> > $LFS_TGT in their CC configure overrides that ones sees in the
> > Chapter 5 Ncurses
> > 
> > zlib.xml:CC="gcc -m32" \
> > zlib.xml:CC="gcc -mx32" \
> > 
> > Cf
> > 
> > ncurses.xml:CC="$LFS_TGT-gcc
> > -m32"  \
> > ncurses.xml:CC="$LFS_TGT-gcc
> > -mx32" \
> > 
> > Hoping that helps, and thanks again for the Mulitlib additions,
> > Kevin
> 
> 
> What I have since discovered is that the Configure script for Zlib
> doesn't
> accept the --host= argument, hence, I guess, the use of the CC=
> constructs
> in the Multilib stanzas.
> 
> With that in mind, the x86_64 configure probably needs to be marked
> up as
> 
> CC="$LFS_TGT-gcc"   \
> ./configure --prefix=/usr
> 
> so as to enforce the use of the compiler in /tools/bin.

Actually, I'm amazed to see zlib in chapter 6 of the multilib book. In
the pure x86_64 (or i686) book, it is not built there at all (only in
chapter 8). 

Thomas, do you remember why it was added there (was on June 29th)?

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Adding attributes in the source XML

[Pierre Labastie via lfs-dev]

On Tue, 2020-10-06 at 18:48 +0800, Kevin Buckley via lfs-dev wrote:
> i was experimenting with making use of an extra attribute in the
> XML source tags, akin to the vanilla book's  'sysv'  or 'systemd'
> for the "revision" attribute,, or to Thomas's Multilib arch attribute
> ('ml_32', 'ml_x32' or 'ml_all').
> 
> When i come to render my source, having added an extra
> stringparam to the xsltproc invocations, vis
> 
> --stringparam profile.revision $(REV) \
> --stringparam profile.arch $(ARCH)\
> --stringparam profile.pkguser $(PKGUSER)\
> 
> I get told
> 
> validity error : No declaration for attribute pkguser of element
> 
> 
> I realise that I have missed adding such a declaration into one of
> the
> stylesheet, or other ancillary, files but I can't determine, by
> inspection
> of many of those files, where such a declaration needs to go.
> 
> Where should such a declaration go?

The attribute has to be declared in the dtd (document type definition),
where anything pertaining to the xml document is declared (not only
attributes, but also tags and their content). For our docbook xml
sources, the dtd is pretty big, and comes from docbook. So you should
look at https://tdg.docbook.org/tdg/4.5/docbook.html, which gives the
details and the use of all tags and attributes. "revision" and "arch"
are attributes defined in the dtd. "pkguser" is not. But maybe,
condition="pkguser" could be used, since condition is a declared
attribute (
https://tdg.docbook.org/tdg/4.5/ref-elements.html#common.attributes),
and the stringparam profile.condition="pkguser" for profiling. Another
attribute name could be "userlevel"... Note that any attribute name
declared in the dtd could be used provided _you_ know what you use it
for, if you do not want to share your work.

Pierre



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Linux API Headers not installed in Chapter 8

[Pierre Labastie via lfs-dev]

On Tue, 2020-09-22 at 22:43 +0200, Tim Tassonis via lfs-dev wrote:
> Hi all
> 
> While building lfs 10.0 from the book, I noticed that the linux api 
> headers are installed in chapter 5, but not again in chapter 8.
> 
> While this of course works, as they are installed into /usr, it seems
> a 
> bit inconsequential to me, as everything else seems to get re-
> installed 
> in chapter 8.
> 
> Is this an error, or is this on purpose?
> 

Not an error, not really "on purpose": just that no change is expected,
because there's no compilation, no linking, not even a sed or
whatever...

All the other packages have a new compiler compared to chapter 6 or 7
(or are completely new, such as man pages).

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] make check fails in binutils, chapter 8.18

[Pierre Labastie via lfs-dev]

On Thu, 2020-09-24 at 21:17 +0200, Tim Tassonis via lfs-dev wrote:
> Hi all
> 
> make -k check fails on my lfs 10.0 build, with following errors:
> 
> after a while, I get this
> 
> gcctestdir/collect-ld: internal error in set_section_addresses, at 
> ../../gold/output.cc:4445
> collect2: error: ld returned 1 exit status
> make[5]: *** [Makefile:9503: incremental_copy_test] Error 1
> 

looks like you missed (or you mistypedp the following:
sed -i '/@\tincremental_copy/d' gold/testsuite/Makefile.in

> 
> then, this:
> 
> 
> make[5]: Leaving directory '/lgl-bld/binutils-
> 2.35/build/gold/testsuite'
> make[4]: *** [Makefile:7743: check-am] Error 2
> make[4]: Leaving directory '/lgl-bld/binutils-
> 2.35/build/gold/testsuite'
> make[3]: *** [Makefile:7747: check] Error 2
> 
> 
> later on, this seems fine
> 
> =
> ===
> Testsuite summary for gold 0.1
> =
> ===
> # TOTAL: 4
> # PASS:  4
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  0
> # XPASS: 0
> # ERROR: 0
>   === ld Summary ===
> 
> # of expected passes  2565
> # of expected failures57
> # of untested testcases   1
> # of unsupported tests23
> ./ld-new 2.35
> 
> At the end, I get this:
> 
> 
> make[1]: Target 'check-host' not remade because of errors.
> make[1]: Nothing to be done for 'check-target'.
> make[1]: Leaving directory '/lgl-bld/binutils-2.35/build'
> make: *** [Makefile:2238: do-check] Error 2
> make: Target 'check' not remade because of errors.
> 
> 
> 
> Is this a known behaviour, or did I fuck up somewhere?
> 
> 
> Bye
> Tim

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] host /usr/share/config.site may break build

[Pierre Labastie via lfs-dev]

On Fri, 2020-09-04 at 00:47 -0500, Bruce Dubbs via lfs-dev wrote:
> On 9/3/20 10:53 PM, Xi Ruoyao via lfs-dev wrote:
> > Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary
> > Tools".  The
> > problem is that configure scripts (generated by autoconf) will try
> > to load
> > ${prefix}/share/config.site and ${prefix}/etc/config.site.  These
> > things are
> > really "powerful" - they can even override some command line
> > options.
> > 
> > "/usr/etc" should not exist on any FHS-compilant distro, but
> > "/usr/share/config.site" exists on many distros.
> > 
> > My suggestion is to add `export CONFIG_SITE=/dev/null` in
> > /home/lfs/.bashrc.  It
> > would override the default config.site search rule.
> 
> I don't know that we have ${prefix}/etc/config.site.  I do  not.  I
> do 
> have /usr/etc/xdg/autostart/xfce4-notifyd.desktop that was installed 
> yesterday when I updated xfce4-notifyd.
> 
> We probably need to specify --sysconfdir=/etc for that.
> 

As an example, fedora has /usr/share/config.site in the autoconf
package. This one is smart and is skipped in case of cross compilation,
but just in case, I second Xi Ruoyao's proposal. Or even to have

CONFIG_SITE=$LFS/usr/share/config.site

We might then create a config.site for our own use, for example with
prefix=/usr
sysconfdir=/etc
localestatedir=/var
sharedstatedir=/var

That would prevent the need to have those in the configure commands...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] gcc-9.2.0 test suite

[Pierre Labastie via lfs-dev]

On Wed, 2020-09-02 at 07:52 -0700, Tree Davies via lfs-dev wrote:
> Hi Everyone,
> 
> I automated my LFS build, and haven't had any issue with it. The
> other day
> during a rebuild, I notiiced that I had been running the gcc test
> suite
> as the root user. So I fixed it as in the intructions: 
> http://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter06/gcc.html
> 
> But now the test suite fails. 
> The output: https://pastebin.com/jaqP9b5Y

At line 6, it seems there is a "cd ..".
It looks like this just follows the "chown -Rv nobody ." line.

This is not what is in the book. Maybe you have a typo in your script?

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Section 9.4 (sysvinit)

[Pierre Labastie via lfs-dev]

On Tue, 2020-08-25 at 17:48 -0400, Joe Locash via lfs-dev wrote:
> In managing devices, specifically WRT network devices, 2 methods are
> listed for using traditional network names. Another and easier (IMO)
> way is to just create an empty file: /etc/udev/rules.d/80-net-name-
> slot.rules

Do you mean you can get rid of 70-persistent-net.rules, even if there
are two or more ethernet cards (not talking about wifi cards)? And if
so, can we be sure that the naming is consistent from one reboot to the
other?

Pierre



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] TCL tests hang on some host systems

[Pierre Labastie via lfs-dev]

On Tue, 2020-08-25 at 06:43 +0200, Pierre Labastie via lfs-dev wrote:
> On Mon, 2020-08-24 at 19:38 -0500, Douglas R. Reno via lfs-dev wrote:
> > Hi folks,
> > 
> > I wanted to drop in a report from my adventures attempting to get
> > LFS 
> > 10.0-rc1 bootstrapped on a VMWare VM for the xf86-video-vmware
> > driver. 
> > Here's some supporting information first:
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ cat /etc/lfs-release
> > 20190511-systemd
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ uname -a
> > Linux RENODR-SAMBATEST-VM 5.1.11 #1 SMP Tue Jun 18 01:16:29 CDT
> > 2019 
> > x86_64 GNU/Linux
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ ldd --version
> > ldd (GNU libc) 2.29
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying
> > conditions.  There
> > is 
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> > PURPOSE.
> > Written by Roland McGrath and Ulrich Drepper.
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ ld --version
> > GNU ld (GNU Binutils) 2.32
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the
> > terms 
> > of
> > the GNU General Public License version 3 or (at your option) a
> > later 
> > version.
> > This program has absolutely no warranty.
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ cc --version
> > cc (GCC) 9.1.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying
> > conditions.  There
> > is 
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> > PURPOSE.
> > 
> > renodr [ /mnt/lfs/blfs_root ]$ bash --version
> > GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > <http://gnu.org/licenses/gpl.html>
> > 
> > This is free software; you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > 
> > 
> > In summary, that's the following:
> > 
> > Kernel: 5.1.11
> > LFS Version: SVN-20190511-systemd
> > GCC Version: 9.1.0
> > Binutils Version: 2.32
> > Glibc Version: 2.29
> > Bash: 5.0.0(1)
> > Processor: Intel Core i7-5820k (using 4 out of 6 cores in this VM).
> > In case it matters, my VMWare version is: VMWare Workstation 15
> > Pro, 
> > version 15.5.6.
> > 
> > This is the only version of LFS that I have installed on this VM
> > that
> > is 
> > far enough to use jhalfs. My end goal was to use blfs-tool through 
> > jhalfs to build it through to Xorg, but I'm on the fence about that
> > at 
> > the moment.
> > 
> > Currently in the test logs:
> > 
> >  http-6.1 http::ProxyRequired FAILED
> >  Contents of test case:
> > 
> >  http::config -proxyhost ${::HOST} -proxyport $port
> >  set token [http::geturl $url]
> >  http::wait $token
> >  upvar #0 $token data
> >  set data(body)
> > 
> >  Test generated error; Return code was: 1
> >  Return code should have been one of: 0 2
> >  errorInfo: couldn't open socket: Name or service not known
> >  while executing
> > "::socket -async RENODR-SAMBATEST-VM 8010"
> >  ("eval" body line 1)
> >  invoked from within
> > "eval $defcmd $sockopts $targetAddr"
> >  invoked from within
> > "http::geturl $url"
> >  ("uplevel" body line 3)
> >  invoked from within
> > "uplevel 1 $script"
> >  errorCode: NONE
> >  http-6.1 FAILED
> > 
> > http11.test
> > 
> > 
> > ^^^ Note that all of the http tests failed prior to the hang. This
> > is 
> > similar to a problem that Ken brought up a week or so ago about
> > test 
> > suite failures.
> > 
> > As of the writing of this email, it's been stuck for about 35
> > minutes. I 
> > am going to kill the process after I send this off to allow jhalfs
> > to 
> > continue.
> 
> I think I have seen hangs in the early testing of the new method, and
> that's why I'd removed the tests for tcl. They have been reinstated,
> and so far, I've seen no hang. Hmmm, could it be some host issue? My
> first tests of the new method were on an old debian version (debian
> 8).
> 
> Another thing to test...
> 

Well, all tests passed except the "clock" one, and no hang.
Will try other VMs I have.
Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] TCL tests hang on some host systems

[Pierre Labastie via lfs-dev]

On Mon, 2020-08-24 at 19:38 -0500, Douglas R. Reno via lfs-dev wrote:
> Hi folks,
> 
> I wanted to drop in a report from my adventures attempting to get
> LFS 
> 10.0-rc1 bootstrapped on a VMWare VM for the xf86-video-vmware
> driver. 
> Here's some supporting information first:
> 
> renodr [ /mnt/lfs/blfs_root ]$ cat /etc/lfs-release
> 20190511-systemd
> 
> renodr [ /mnt/lfs/blfs_root ]$ uname -a
> Linux RENODR-SAMBATEST-VM 5.1.11 #1 SMP Tue Jun 18 01:16:29 CDT 2019 
> x86_64 GNU/Linux
> 
> renodr [ /mnt/lfs/blfs_root ]$ ldd --version
> ldd (GNU libc) 2.29
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is 
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> Written by Roland McGrath and Ulrich Drepper.
> 
> renodr [ /mnt/lfs/blfs_root ]$ ld --version
> GNU ld (GNU Binutils) 2.32
> Copyright (C) 2019 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the
> terms 
> of
> the GNU General Public License version 3 or (at your option) a later 
> version.
> This program has absolutely no warranty.
> 
> renodr [ /mnt/lfs/blfs_root ]$ cc --version
> cc (GCC) 9.1.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is 
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
> renodr [ /mnt/lfs/blfs_root ]$ bash --version
> GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> 
> In summary, that's the following:
> 
> Kernel: 5.1.11
> LFS Version: SVN-20190511-systemd
> GCC Version: 9.1.0
> Binutils Version: 2.32
> Glibc Version: 2.29
> Bash: 5.0.0(1)
> Processor: Intel Core i7-5820k (using 4 out of 6 cores in this VM).
> In case it matters, my VMWare version is: VMWare Workstation 15 Pro, 
> version 15.5.6.
> 
> This is the only version of LFS that I have installed on this VM that
> is 
> far enough to use jhalfs. My end goal was to use blfs-tool through 
> jhalfs to build it through to Xorg, but I'm on the fence about that
> at 
> the moment.
> 
> Currently in the test logs:
> 
>  http-6.1 http::ProxyRequired FAILED
>  Contents of test case:
> 
>  http::config -proxyhost ${::HOST} -proxyport $port
>  set token [http::geturl $url]
>  http::wait $token
>  upvar #0 $token data
>  set data(body)
> 
>  Test generated error; Return code was: 1
>  Return code should have been one of: 0 2
>  errorInfo: couldn't open socket: Name or service not known
>  while executing
> "::socket -async RENODR-SAMBATEST-VM 8010"
>  ("eval" body line 1)
>  invoked from within
> "eval $defcmd $sockopts $targetAddr"
>  invoked from within
> "http::geturl $url"
>  ("uplevel" body line 3)
>  invoked from within
> "uplevel 1 $script"
>  errorCode: NONE
>  http-6.1 FAILED
> 
> http11.test
> 
> 
> ^^^ Note that all of the http tests failed prior to the hang. This
> is 
> similar to a problem that Ken brought up a week or so ago about test 
> suite failures.
> 
> As of the writing of this email, it's been stuck for about 35
> minutes. I 
> am going to kill the process after I send this off to allow jhalfs
> to 
> continue.

I think I have seen hangs in the early testing of the new method, and
that's why I'd removed the tests for tcl. They have been reinstated,
and so far, I've seen no hang. Hmmm, could it be some host issue? My
first tests of the new method were on an old debian version (debian 8).

Another thing to test...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] M4 in chapter 6 fails to compile

[Pierre Labastie via lfs-dev]

On Thu, 2020-08-20 at 17:28 +0100, John Burrell via lfs-dev wrote:
> I get this result
> 
> make[3]: Entering directory '/mnt/lfs/build/m4/m4-1.4.18/lib'
>   CC   gl_avltree_oset.o
>   CC   binary-io.o
>   CC   c-ctype.o
>   CC   c-stack.o
>   CC   c-strcasecmp.o
>   CC   c-strncasecmp.o
>   CC   clean-temp.o
> In file included from /mnt/lfs/usr/include/stdlib.h:1018,
>  from ./stdlib.h:36,
>  from clean-temp.c:29:
> /mnt/lfs/usr/include/bits/stdlib.h: In function 'wctomb':
> /mnt/lfs/usr/include/bits/stdlib.h:91:3: error: #error "Assumed value
> of MB_LEN_MAX wrong"
>91 | # error "Assumed value of MB_LEN_MAX wrong"
>   |   ^
> make[3]: *** [Makefile:1910: clean-temp.o] Error 1
> make[3]: Leaving directory '/mnt/lfs/build/m4/m4-1.4.18/lib'
> make[2]: *** [Makefile:1674: all] Error 2
> 
> Arch applies quite a substantial patch which allows it to compile. I
> don't know which bit of the patch fixes the above problem I'm afraid
> 
> jb.

There is no need for a patch at this stage, but I think there is
something wrong in the limits.h header. Have you run the instructions
at the end of gcc pass 1 and glibc in chapter 5?

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] libcap-2.42 No rule to make target 'install-static'

[Pierre Labastie via lfs-dev]

On Tue, 2020-08-11 at 05:09 +0100, Ken Moffat via lfs-dev wrote:
> Trying to build current svn, libcap install failed:
> 
> make -C libcap install
> make[1]: *** No rule to make target 'install-static', needed by
> 'install'.  Stop.
> make[1]: *** Waiting for unfinished jobs
> make[1]: Entering directory '/building/libcap-2.42/libcap'
> mkdir -p -m 0755 /usr/include/sys
> install -m 0644 include/sys/capability.h /usr/include/sys
> install -m 0644 include/sys/psx_syscall.h /usr/include/sys
> mkdir -p -m 0755 /usr/lib/pkgconfig
> install -m 0644 libcap.pc /usr/lib/pkgconfig/libcap.pc
> install -m 0644 libpsx.pc /usr/lib/pkgconfig/libpsx.pc
> mkdir -p -m 0755 /lib
> install -m 0644 libpsx.a /lib/libpsx.a
> make[1]: Leaving directory '/building/libcap-2.42/libcap'
> make: *** [Makefile:12: install] Error 2
> 
> I suspect that the sed to prevent the static lib being installed is
> inadequate.  In libcap/Makefile at this point:
> 

The sed has been slightly changed to prevent this. Have you noticed it?
It was
sed -i '/install.*STACAPLIBNAME/d' libcap/Makefile
It is now
sed -i '/install -m.*STACAPLIBNAME/d' libcap/Makefile

> install: install-shared install-static
> 
> Since I don't understand the details of libcap and I want to leave
> the build running I've commented out the sed in my current build.
> 
> I will also remark that current 'make' seems to like runing multiple
> jobs in the install, I've seen it before - in this case the command
> was just
>  make lib=lib PKGCONFIGDIR=/usr/lib/pkgconfig install
> although I use make -j8 for the actual build.
> 
> ĸen
> -- 
> Juliet's version of cleanliness was next to godliness, which was to
> say it was erratic, past all understanding and was seldom seen.
>   -- Unseen Academicals


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] report: test build with glibc-development, and old updated packages

[Pierre Labastie via lfs-dev]

On Sun, 2020-08-02 at 22:10 +0200, Pierre Labastie via lfs-dev wrote:
> 
> But the sed or the whole patch for binutils gold tests is (are) still
> needed. I haven't had the time to get to the exact requirements...
> 

Just to confirm that only the sed is needed. The patch has been
included upstream.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] report: test build with glibc-development, and old updated packages

[Pierre Labastie via lfs-dev]

I've done a test build with git version of glibc, and all other
packages updated. I've forgotten the beta version of autoconf.

The patch for gcc pass 2 is not needed anymore.

But the sed or the whole patch for binutils gold tests is (are) still
needed. I haven't had the time to get to the exact requirements...

With the git version of glibc, one more test fails, besides misc/tst-
ttyname (BTW, Ken, when this one does not fail, isn't it in the
UNSUPPORTED list?): io/tst-lchmod.

I also have a lot of failures in gcc tests:
6 in libstdc++ (the usual locale/time_get/get_time failures
7 in gcc (gcc.dg/asan/pr80166.c in various conditions)
17 in g++ (all in g++.dg/coroutines/torture)

Also, as reported in ticket #4700, all pipeline tests fail with the new
check version. I've proposed a sed, which I hope can be further
simplified...

All in all, the build went ok. And the system boots (in a VM) without
difficulty.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] More observations on directory creations

[Pierre Labastie via lfs-dev]

On Sat, 2020-08-01 at 16:16 -0500, Bruce Dubbs via lfs-dev wrote:
> 
> 
> All mkdir commands should use -p whether needed or not, just for 
> consistency.

I'm not sure that "consistency" is the right word here: using an option
consistently means using it when it is needed...

Maybe "regularity" or so.

> An exception can be made for mkdir -v build instructions 
> where needed.
> 
> I think the entire directory tree should continue to be specified in 
> Section 7.5. Creating Directories

Why? I'm more and more thinking that with the new layout, the place for
"creating directories" is in chapter 4.

> but adding a note that some of the 
> directories have already been created by commands earlier in the book
> or 
> by earlier package install instructions, but are repeated for 
> completeness and do not affect existing directories.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] More observations on directory creations

[Pierre Labastie via lfs-dev]

Hi,
Exceptionally top-posting, because, I'll answer in the message body,
and I want to tell general things first.
First, thanks to Kevin to be our "quality assurance". Those messages
are bugging me, but make me think...
Second, presently, the whole management of directories is the result of
design decisions made at the beginning of the testing of the new
method. Some of those decisions may seem wrong now, but that was not
evident at the time. Specially, the first aim was to have a working
build, not necessarily the best explanations...
Third, one of those decisions was to keep $LFS owned and only writable
by root. At the time, it was thought that it could prevent unwanted
behavior in chapter 6, for example alert on non desirable directory
creation. In retrospect, it was maybe not necessary, and having $LFS
writable by lfs could simplify things a lot.
That said, here are a few comments...

On Sat, 2020-08-01 at 15:42 +0800, Kevin Buckley via lfs-dev wrote:
> As some of you will be aware from other threads, I have been
> spending way too much time looking at the way that the LFS
> book goes about creating its directory hierarchy, but for those
> of you who find these things interesting, here's some more.
> 
> Here's what the current (r12002) book does, as regards creating
> the required directory hierarchy, in two separate parts:
> 
> 4.2
> 
> mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin}

the order is a result of adding directories as needed for chapter 6
installations. They did not come in alphabetical order. Now they can be
sorted...

> case $(uname -m) in
>   x86_64) mkdir -pv $LFS/lib64 ;;
> esac
> 
> mkdir -pv $LFS/tools
> 
> 
> 4.3
> 
> chown -v lfs $LFS/{usr,lib,var,etc,bin,sbin,tools}

alphabetical sort here too.

> case $(uname -m) in
>   x86_64) chown -v lfs $LFS/lib64 ;;
> esac
> 
> 
> 7.2
> 
> chown -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools}

and here again

> case $(uname -m) in
>   x86_64) chown -R root:root $LFS/lib64 ;;
> esac
> 
> 
> 7.5
> 
> mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib/firmware,mnt,opt}

At first, /bin was not used in chapter 6. Now it is, and shouldn't
appear here.
/etc, and /lib already exist. the -p option is not needed

> mkdir -pv /{media/{floppy,cdrom},srv,var}

Again, /var was added later in the minimal set. May be removed here.
/media does not exist yet, so the -p option is needed.

> mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}

Here, we should separate /usr and /usr/local:
/usr/{bin,include,lib,sbin} exist from chapter 6. The equivalent in
/usr/local does not. OTOH, we may want to have the whole structure in
one place (which means probably adding sbin to the first line)

> mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}

Again, some of those already exist from chapter 6

> mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}

Same here (terminfo)

> mkdir -pv /usr/{,local/}share/man/man{1..8}

And again here

> install -dv -m 1777 /tmp /var/tmp
> install -dv -m 0750 /root
> 
> mkdir -v /var/{log,mail,spool}
> ln -sv /run /var/run
> ln -sv /run/lock /var/lock
> mkdir -pv /var/{opt,cache,lib/{color,misc,locate},local}
> 
> 
> Leaving aside the non-alphabetical ordering of the directories
> in the Chapter 4 commands,
> 
> I wondered why the first two lines of commands in 7.5 duplicate
> the creation, in 4.2, of
> 
> /bin
> /var

answered above...

> 
> but not any of the other "top-level" directories from 4.2, so
> 
> /etc /lib /lib64 /sbin /usr

with mkdir -p, those directories would be created if they did not
exist. But I agree, /var could be left for later, when creating
subdirectories in /var (using mkdir -p)

> 
> that get created in 4.2?
> 
> I do note though that /etc, /lib and /usr are implicitly created
> when subdirectories of them are, so could ask a slightly different
> question, vis:
> 
> Why is the creation of /sbin not duplicated?

Good question. Having the whole directory structure on one page might
be better for understanding. I (and Thomas) wonder whether this
structure couldn't even be created in chapter 4, selectively changing
ownership of directories where the lfs user needs to be able to write.
> 
> 
> I also wondered why the first mkdir for subdirectories of /var
> 
> mkdir -v /var/{log,mail,spool}
> 
> doesn't have a "-p", in common with all the other mkdir-s,
> including the creation of the top-level directories.

It does not have a -p because it is not needed. But then the first line
does not need it either... Not very consistent, as you say.

> 
> I'd suggest that the 7.5 commands would be better laid out as
> 
> 
> Create some root-level directories that are not in the limited set
> required for Chapters 4, 5 and 6.
> 
> mkdir -pv /{boot,home,mnt,opt,srv}
> 
> Create the required set of subdirectories below the root-level
> 
> mkdir -pv /etc/{opt,sysconfig}
> mkdir -pv /lib/firmware
> mkdir -pv /media/{floppy,cdrom}
> mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}
> mkdir -pv 

Re: [lfs-dev] Some files on the final system are now created during the temporary tools phase

[Pierre Labastie via lfs-dev]

On Fri, 2020-07-31 at 15:22 -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/31/20 2:14 PM, Marcel van den Boer via lfs-dev wrote:
> 
> Thanks for this,
> 
> > I compared a completed system of SVN-20200721 with a backup of the 
> > temporary system and found that a few files from the temporary
> > system 
> > are not reinstalled on the final system as a side effect of the new
> > way 
> > of building LFS.
> > 
> > (1) Gawk hardlink.
> > /usr/bin/gawk-5.1.0 is still pointing to the temporary version of
> > the 
> > software. 'make install' does not replace this file if it already
> > exists.
> > Possible fix is to just remove the link before rebuilding, or patch
> > the 
> > Makefile to always overwrite it.
> 
> I think
>sed -i '/LN =/ s/$/ -f/' Makefile.in
> can fix this.  I've not tested yet.
> 
> > (2) Perl.
> > Lots of files are not reinstalled, but are kept from the chapter 7
> > build 
> > instead. Not sure if these should be removed, if they should have
> > been 
> > rebuilt in chapter 8, or if Perl is aware of these files and does
> > not 
> > reinstall them if they are already present.
> > - 
> > /usr/lib/perl5/5.32/core_perl/{B,B.pm,Compress,Config.pod,Config_gi
> > t.pl,Cwd.pm,..., > more>}
> > - 
> > /usr/share/perl5/core_perl/{AnyDBM_File.pm,App,Archive,Attribute,Au
> > toLoader.pm,AutoSplit.pm,..., > more>}
> 
> We can try 'rm -rf /usr/lib/perl5' at teh start of Chapter 8.
> 
> > (3) Glibc header file (/usr/include/gnu/stubs-64.h).
> > Not sure about this one either. Could be that the build compares
> > the 
> > existing file and chooses not to overwrite it if it is unchanged.
> > The 
> > other 5 files in the same directory (like 'lib-names-64.h' and 
> > 'stubs.h') are re-created though.
> 
> We will need to wait for glibc-2.32 (due tomorrow) to check this.
> 
> > (4) All Linux API Headers.
> > This is probably as intended in this new set up. But you may want
> > to 
> > clarify in the book that most (if not all) of these headers are
> > kept on 
> > the final system, even though they are installed during the 
> > cross/temporary build phase.
> 
> Yes, the headers will not change between Chapters 7 and 10. I'm not
> sure 
> it is necessary to explain to the level of detail you suggest.
> 
> > (5) A few symlinks are now created way before chapter 8.
> > This is not an issue for most LFS builders. But it is good to know
> > that 
> > these are left out on your system if you only capture the files
> > built in 
> > chapter 8 for package management.
> > - /bin/sh
> > - /lib64/ld-linux-x86-64.so.2
> > - /lib64/ld-lsb-x86-64.so.3
> > - /usr/bin/awk
> > - /usr/bin/cc
> > I'm used to making package archives from the builds that are now
> > in 
> > chapter 8, and if some files remain untouched in that phase, they
> > are 
> > not captured at all right now. So, if (2) and (3) are not bugs,
> > then I 
> > may have to change my capture mechanism to begin tracking files
> > right 
> > from the start of the build.
> 
> We really don't support package management directly in the book.  I 
> think this type of information should go into a hint. 
> more_control_and_pkg_man.txt would be the most likely candidate if
> you 
> want to update it.

The problem doesn't occur with pacman/rpm/dpkg... because they do a
DESTDIR install, so always see a clean directory (note that installing
the package to the system requires to allow overwriting files).

But for PMs like porg, which log installed files, the problem is the
same as above.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Bootscript checkfs anomoly

[Pierre Labastie via lfs-dev]

On Fri, 2020-07-31 at 14:54 -0500, William Harrington via lfs-dev
wrote:
> I tried to provide the community a possible problem. Since the
> community doesn’t like images, so where do I post proof?
> 
> > On Jul 31, 2020, at 14:05, William Harrington <
> > kb0...@berzerkula.org> wrote:
> > 
> > 
> > 
> > > > On Jul 31, 2020, at 12:25, Bruce Dubbs via lfs-dev <
> > > > lfs-dev@lists.linuxfromscratch.org> wrote:
> > > > 
> > > > On 7/31/20 11:47 AM, William Harrington via lfs-dev wrote:
> > > > Greetings,
> > > > While checking file systems, the line at 131 will omit ‘Y’. The
> > > > message ends up being “ou may want to double-check that”.  I
> > > > had to remove the character before ‘Y’ to correct the output.
> > > > Please verify.
> > > 
> > > The only place in that file that has the word 'You' is on line
> > > 97:
> > > 
> > > 
> > > msg="\nWARNING:\n\nFile system errors "
> > > msg="${msg}were found and have been corrected.\n"
> > > msg="${msg} You may want to double-check that "
> > > msg="${msg}everything was fixed properly."
> > > 
> > > log_warning_msg "$msg"
> > > 
> > > I think the number of spaces before 'You' may need to be
> > > increased by one because the function log_warning_msg sets the
> > > cursor to column 1 and writes ' ***  ' after the message has been
> > > written.  Can you add that space and test?  Thanks.
> > > 
> > > -- Bruce
> > > -- 
> > > http://lists.linuxfromscratch.org/listinfo/lfs-dev
> > > FAQ: http://www.linuxfromscratch.org/faq/
> > > Unsubscribe: See the above information page
> > 
> > Greetings,
> > 
> > I remove the character (not necessarily a space)
> > When you look in vim it’s a character over.  Make your file system
> > dirty and do a check, you’ll see that Y isn’t there.

William, nobody says that Y is there (actually, I confirmed it is not).
Bruce told to change the /etc/init.d/checkfs file to fix/work around
the problem. You said something else (I'm not sure actually what you
do), which might be used as well as a fix.

Actually, looking at the bootscripts, I think all the multiline log
messages should be reworked.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Creating the Minimal directory layout in LFS filesystem

[Pierre Labastie via lfs-dev]

On Sun, 2020-07-26 at 12:18 -0500, Bruce Dubbs via lfs-dev wrote:
> On 7/26/20 6:35 AM, Kevin Buckley via lfs-dev wrote:
> > At present, the LFS Book, at Revision r12002, says
> > 
> > 4.2. Creating the Minimal directory layout in LFS filesystem
> > 
> > The first task performed in the LFS partition is to create a
> > minimal
> > directory hierarchy so that programs compiled in Chapter 6 may be
> > installed in their final location. This is needed so that those
> > temporary programs be overwritten when rebuilding them in Chapter
> > 8.
> > 
> > Create the required directory layout by running the following as
> > root:
> > 
> > mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin}
> > case $(uname -m) in
> >x86_64) mkdir -pv $LFS/lib64 ;;
> > esac
> > 
> > however, the "This is needed ..." statement is not actually true.
> > 
> > I've noticed that when building the Chapter 5 tools, that you only
> > really need
> > 
> >$LFS/usr
> > 
> > so as to allow Linux Headers to do this
> > 
> >cp -rv usr/include $LFS/usr
> > 
> > and
> > 
> >$LFS/lib
> >$LFS/lib64
> > 
> > because of the compatibility links that get added at the start of
> > Chapter 5's Glibc.
> > 
> > The install of Chapter 5's Glibc creates the following "top-level"
> > directories
> > 
> > lib, var, etc, sbin
> > 
> > when it does, amongst other "mkdir -p" invocations, the following
> > 
> > mkdir -p -- /media/lfs10/lib
> > mkdir -p -- /media/lfs10/var/lib/nss_db
> > mkdir -p -- /media/lfs10/etc
> > mkdir -p -- /media/lfs10/sbin
> > 
> > and indeed, at the end of Chapter 5, there is still no /bin below
> > $LFS.
> > 
> > As I see it, it's not until Chapter 6's Bash, where the bash binary
> > gets moved to /bin, that that directory is required, so perhaps the
> > minimal directory list could just be
> > 
> > mkdir -pv $LFS/{bin,lib,usr}
> > case $(uname -m) in
> >x86_64) mkdir -pv $LFS/lib64 ;;
> > esac
> > 
> > and even then the lib and lib64 directories are only required in
> > the Glibc
> > section because explicit links are made there, so the creation of
> > those
> > directories could be made part of Chapter 5's Glibc.
> > 
> > Note also that Chapter 6's Bash install, doesn't require $LFS/bin:
> > it's
> > the "by-hand" move of the bash binary that requires it.
> > 
> > If the creation of /bin was made a part of the Chapter 6 Bash
> > install,
> > as that is the first place that /bin is required, that would leave
> > Chapter 4
> > with just this
> > 
> > mkdir -pv $LFS/usr
> > 
> > Just some observations that might be of use to some though,
> 
> I haven't checked, but I think you may be taking the word 'minimal'
> too 
> literally.  Perhaps we should just change the description to:
> 
> Creating a Limited directory layout in LFS filesystem
> 
> Whether or not all the directories created in Chapter 4 are needed
> in 
> Chapters 5 and 6, they are certainly needed in Chapters 7 and
> 8.  When 
> they are created is really not very important.
> 

The LFS root directory ($LFS), is supposed to be owned by the root
user, and to have permissions rwxr-xr-x, so that user lfs cannot create
anything in it. That's the reason why we create the hierarchy as root
and chown the dirs to lfs later.

I think Kevin has $LFS owned by lfs (or different permissions), which
is of course ok, provided ownership or permissions are changed at the
end.

Right now, this is not what is done in the book.

Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Errors with Linux From Scratch Version SVN-20200707

[Pierre Labastie via lfs-dev]

On Sat, 2020-07-11 at 11:28 +, John Frankish via lfs-dev wrote:
> A couple of errors found:
> 
> Chapter 6. Cross Compiling Temporary Tools
> 6.7. File-5.39
> 
> Building gives the error:
> 
> Cannot use the installed version of file (5.37) to
> cross-compile file 5.39
> Please install file 5.39 locally first
> 
> ..fixed by updating file on the host.

When faking cross compilation, and using the instructions in the book
(that is, not passing --build=$(./config.guess)), the build system is
aware that it can use the just built file to compile the "magic" file,
and so it does... If doing a true cross compilation, this error will
occur; two solutions:
- as you did, update file on host
- first compile a local "file" executable, similarly to what is done
  with ncurses

(see Also what Xi Ruoyao has said about that, his mail arrived while I
was writing this one)

Note that we cannot change Makefile.am and use autoreconf, because we
do not require autotools on the host.

> 
> Chapter 6. Cross Compiling Temporary Tools
> 6.10. Grep-3.4
> 
> Building pulls in a dep on libpcre from the host, which causes
> problems later, but can be fixed with "--disable-perl-regexp"

Normally, this shouldn't happen: configure makes two tests, one is
using pkg-config to find libpcre, the second is testing whether some
function from the library can be called. The second one should fail in
a cross-compiling environment, if sysroot is correctly set.

(creating a fake pkg-config as suggested by Xi Ruoyao shouldn't be
needed, at least if compiling on x86 for x86)

> 
> Also, but probably out of scope,
> 
> Chapter 5. Compiling a Cross-Toolchain
> 5.5. Glibc-2.31
> 
> Fails for arm (RPi) with a long double error fixed with an upstream
> patch:
> 
> https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html

We may want to make chapter 5/6 more compatible with a general cross-
compilation environment (at least x86->arm). I cannot look at that ATM.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] libelf

[Pierre Labastie via lfs-dev]

On Tue, 2020-07-07 at 11:56 +0100, Roger via lfs-dev wrote:
> Yesterday I built LFS-9.1 (sysvinit not systemd) with /usr 
> on a separate partition. Localnet failed when I booted. This 
> is because ip (from iproute2) links to libelf which is in
> /usr/lib. Localnet is run before mounting /usr which means 
> that libelf is unavailable. My quick and easy solution was 
> to move libelf* from /usr/lib to /lib.
> 
> I've just looked at the latest SVN 2020-07-06 and libelf 
> is still before iproute2 so the above would still happen. 
> I don't see any configure option in iproute2 to stop the 
> link to libelf so one solution would be to change the
> instructions for installing libelf. If there's a better 
> way, feel free to use it.

Thanks for the heads-up. It's good that somebody tests with a separate
/usr partition!
We can avoid linking by temporarily moving libelf.pc to another file.
But I do not know what functionality would be lost in the process.

Otherwise, I think we could just add --libdir=/lib to configure in
libelf (and still install the .pc file to /usr/lib, and of course
remove /lib/libelf.a).

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] incorrect note about libstdc++ in toolchain technical notes?

[Pierre Labastie via lfs-dev]

On Sun, 2020-06-21 at 14:18 +0800, Xi Ruoyao via lfs-dev wrote:
> 在 2020-06-21星期日的 14:14 +0800，Xi Ruoyao via lfs-dev写道：
> > > "As said above, the standard C++ library is compiled next,
> > > followed in  > > "
> > > "linkend=\"chapter-temporary-tools\"/> by all the programs that
> > > need "
> > > "themselves to be built. The install step of all those packages
> > > uses the "
> > > "DESTDIR variable to have the programs land into
> > > the LFS "
> > > "filesystem."
> > 
> > "Followed in chapter-temporary-tools" means libstdc++ pass 2, but
> > in pass 2
> > DESTDIR is not installed.  IMO it should be chapter-cross-tools and
> > this
> > libstdc++ means pass 1.
> 
> s/installed/used/
> 
> I can't type :(.
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
> 

Well, the chapter following the first install of libstdc++ is chapter-
temporary-tools (numbered 6 presently). Maybe it is not clear, but what
is meant is:
After the (first) build of libstdc++ comes the installation of all the
programs in chapter 6, and this (first) build of libstdc++ as well as
the build of those programs use DESTDIR (actually also glibc, but this
should maybe be said above).


Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Some comments on the test results.

[Pierre Labastie via lfs-dev]

On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> I've now been through my test logs for the new build (on my i7
> haswell).
> 
> Here are a few comments (in order of testing)
> 
> glibc-2.31.0
> 
> 
> We say "misc/tst-ttyname is known to fail in the LFS chroot
> environment."  But for me it was skipped (I'm running a 5.7.2
> kernel, with 5.7.2 headers and 5.7 iproute2).
> 
> But my log says
> 5102 PASS
>   44 UNSUPPORTED
>   16 XFAIL
>2 XPASS
> 
> And misc/tst-ttyname is now among the unsupported -
> UNSUPPORTED: misc/tst-ttyname

I have quite different results (was with 5.6.15 kernel and headers, and
iproute2-5.6):
  1 FAIL
   5177 PASS
 22 UNSUPPORTED
 17 XFAIL
  2 XPASS

with
FAIL: misc/tst-ttyname

I cannot tell why it has run more tests for me than for you (I mean the
22 less UNSUPPORTED cannot explain the 75 more PASS)

Note that in a VM with an old debian 8 system (kernel 3.16), I have 24
UNSUPPORTED and 5175 PASS, otherwise identical.

> 
> I'm also now wondering about the comment on the rt/tst-cputimer
> tests.  I don't have any systems running kernels older than 5.4, but
> the detail suggests that "mid-period" 4.14 and 4.19 stable kernels,
> as well as some or all of 4.20, failed here.  Could we not just say
> that some kernels before linux-5.0 cause these tests to fail ?

Don't remember, so I trust you. This test passed on the 3.16 debian
kernel, though. But some fixes may have been backported.

> 
> gcc-10.1.0
> --
> 
> I seem to be getting rather more failures than the book implies,
> although I don't think they are either serious or unexpected.
> 
> First, 14 failures i nthe torture test, variants of
> FAIL: gcc.c-torture/compile/limits-exprparen.c

Isn't it the one that fails when ulimit is not increased?

> 
> Second, as wel las the 6 locale/get_time test failures I also had
> FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> FAIL: 22_locale/numpunct/members/char/3.cc execution test

Never seen those ones

Most often, I have only the 6 22_locale/get_time failures on the
Haswell or 64 bit VM's.

On the i686 VM, I had 13 errors for libstdc++, but not the same as the
ones you report.

> 
> bison-3.6.3
> ---
> 
> Here, I strongly disagree that the tests need to be run with -j1.
> 
> On my i3 Skylake last December I had to use -j1 to get the package
> to compile, and therefore I also used -j1 on that machine if I ran
> the tests.  But on other machines I'm using -j8 both for the compile
> and for the tests (and no failures).

Could be changed I guess

> 
> python-3.8.3
> 
> 
> "The test named test_normalization fails because network
> configuration is not completed yet."  I assume that the work on
> /etc/hosts has solved this, I have:
> 
> 0:01:42 load avg: 6.94 [369/423] test_normalization passed --
> running: test_concurrent_futures (1 min 38 sec),
> test_multiprocessing_spawn (1 min 33 sec)
> 
> and at the end it reported SUCCESS before listing the skipped tests.
> 

Not run those since the book tells not to run them

> acl-2.2.53 (tested after coreutils)
> --
> 
> In the past I'd assumed that the two failures I was seeing
> [test/root/permissions.test and test/root/setfacl.test ] were because
> I didn't use ACLs (although ext4 supports them), but that was
> probably a mistaken assumption.  Anyway, now I don't have any
> failures in acl.

Not run either

> 
> util-linux-2.35.2
> -
> 
> I have to admit that this is my first build with this version, I'd
> managed to miss the change to it.  I see that we use 'make -k check'
> in the expectation that things may fail.  And I do get one failure:
> 
> FAILED (column/invalid-multibyte)
> 
> ISTR that has happened in the past, and I had the impression that
> the cross- changes had fixed it, but maybe I'm mistaken.

For me they now all pass (on all my machines). Note that I do not use
any special CFLAGS. Those are all jhalfs builds. The cpu is exactly the
same as yours.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] a typo in Toolchain Technical Notes?

[Pierre Labastie via lfs-dev]

On Thu, 2020-06-18 at 17:03 +0800, Xi Ruoyao via lfs-dev wrote:
> There is a table:
> 
> Stage Build   HostTarget  Action
> 1 A   A   B   build cross-compiler cc1 using ccA on machine
> A
> 2 A   B   B   build cross-compiler cc2 using cc1 on machine
> A
> 3 B   C   C   build compiler ccC using cc2 on machine B
> 
> Should stage 2 be "A B C"?  Without a compiler targeting C we can't
> build ccC,
> which should runn on C.

Sure, sorry. Thanks for noticing. Will fix it.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Thu, 2020-06-18 at 12:37 +0800, Kevin Buckley via lfs-dev wrote:
> On Wed, 17 Jun 2020 at 22:01, Pierre Labastie via lfs-dev
>  wrote:
> > Please tell us what you think of:
> > http://www.linuxfromscratch.org/~pierre/lfs-svn/index.html
> > (I've not bee able to remove the latin numbering in the
> > "Preliminary
> > material")
> 
> Seems a much better separation of the "introductory" and the
> "practical" material.
> 
> Still prefer this one with a "Temporary" added, so
> 
> 7. Entering Chroot and Building Additional Temporary Tools
> 
> so as to reinforce the "Temporary" nature.
> 
> Also suggest that
> 
> 7.17. Finishing Temporary Tools
> 
> reads as more of a
> 
> 7.17 Cleaning up and Saving the Temporary Tools environment

Why "environment"? I'm not sure here. We really save the tools.
And what we "clean up" is not really an environment (rather we
remove unneeded files from the file system).

> 
> or perhaps,
> 
> 7.17 Cleaning up and Saving the Chroot environment

This one, I really dislike: a chroot environment is a set of variables,
not files. We cannot save it either, since actually we have to reenter
it each time.

What about "Cleaning up and Saving the Temporary system"?

> 
> than a "finishing"
> 
> Given your note in another thread, as to the Chroot files being
> overwritten,
> it might be worth making the one final note, reminding people that
> once
> they start using the Chroot to build the LFS system, it's no longer
> the Chroot
> that they started Chapter 8 with, into a Note box in its own right
> 

Put a note at the beginning of the section.

> And there's a typo in the current reminder:
> 
> Unfortunatly, all the temporary tools will be removed, too.
> 
> it's missing the "e" from  Unfortunately,

Thanks. This is "just" a typo here, but I guess we'll find some more
errors: a big rewrite like that implies two very different tasks:
- make the instructions work (lot of trial and error)
- keep the text in sync with the instructions (not always easy since
the first task is a moving target:)

So there may be remnants in the text of all the various paths that have
been followed during the first task and lead to dead ends...

xry111 has already found two (thanks).

Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Stripping Again: loss of suid on some files

[Pierre Labastie via lfs-dev]

On Wed, 2020-06-17 at 19:55 +0100, Ken Moffat via lfs-dev wrote:
> Bringing this here now that Scott Andrews has pointed me towards the
> source of why users could not su on my new system: loss of suid.
> 
> In the past I have not usually run what was in 'Stripping Again'
> because my CFLAGS drop debug information.  But I've now started to
> allow that in elfutils (to get the tests to pass), so I know that at
> least those libs could be stripped.
> 
> What has happened on this build is that all of the bin programs lost
> the suid bit, i.e.
> 
> /bin/{mount,ping,ping6,su,umount}
> /usr/bin/{chage,chfn,chsh,expiry,gpasswd,newgidmap}}
> /usr/bin/{newgidmap,newgrp,newuidmap,passwd,wall}
> 
> Since nobody else has reported this for the moment, I'm merely
> reporting iti, not attempting to fix the book.  In my own script for
> Stripping Again I've now added
> 
> chmod -v 4755 /bin/{mount,ping,ping6,su,umount}
> chmod -v 4755 /usr/bin/{chage,chfn,chsh,expiry,gpasswd}
> chmod -v 4755 /usr/bin/{newgidmap,newgrp,newuidmap,passwd}
> chmod -v 6755 /usr/bin/wall
> 
> Which should ensure that all the suid binaries are correct after
> stripping.

I just tried:
sudo strip /bin/su.
The size was reduced from 139512 to 41424 bytes, and it is still suid
afterwards. Not sure what may explain what happened to you.

Do you have a special umask for root? (only thing I can think of; there
is nothing about permissions in the man page for strip)

Pierre



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Tue, 2020-06-16 at 19:58 +0800, Kevin Buckley via lfs-dev wrote:
> On Mon, 15 Jun 2020 at 20:01, Bruce Dubbs via lfs-dev
>  wrote:
> > > I'd like to see the "cross-compiling 101" sections, so
> > > 
> > > Introduction
> > > Toolchain Technical Notes
> > > General Compilation Instructions
> > > 
> > > in "chapter" 5, separated out from the package build sections
> > > there.
> > 
> > We can possibly put a header in the table of contents like we do
> > for
> > Java in
> > http://www.linuxfromscratch.org/blfs/view/stable/general/prog.html,
> > but
> > the new Chapter 5 is now only 8 pages long.  A separate chapter
> > doesn't
> > make sense to me.
> > 
> > > Appreciate they would make for a very small introductory chapter
> > > but it somehow feels wrong as it is.
> > > 
> > > Not sure if I'd favour the Pass1 and Pass2 sections all being
> > > within
> > > the same chapter or not though, or how one would entitle a
> > > chapter
> > > that just contained just those five package builds, plus yet
> > > another
> > > Introduction.
> > 
> > The pass1/pass2 titles are all in Part III.  In the full book there
> > are
> > really three builds for some packages.  The -pass titles are really
> > to
> > emphasize that the same packages are being built with different
> > procedures fo rthe creation of the tools.
> 
> Yes: all in Part III but is there a need for the Pass1 and Pass2
> sections
> to be separate chapters within that Part.
> 
> In the "old" LFS, the Pass1 and Pass2 sections were both in Chapter
> 5.
> In the proposed LFS, Pass 1 and Pass 2 get separate chapters, one of
> which, as you state, is now just 8 pages long.
> 
> What I was trying to get at before was that these three sections
> 
> > > Introduction
> > > Toolchain Technical Notes
> > > General Compilation Instructions
> 
> are not really an introduction to Chapter 5, so to just the Pass-1
> build instructions, but are really the introduction to Chapters 5 and
> 6, as in to cross-compiling in general.
> 
> As someone else suggested, they might even be "generic" (my wording)
> enough to not need to be in the "building" Parts but be moved up into
> one
> of the "backgrounding" Parts.
> 
> Does that make more sense ? You still don't have to agree with the
> premise
> but I'm not sure I got my view across as well as I might have before,
> in which
> case your reluctance to collapse the new 5 and 6 back into the one
> Chapter
> might not be a response to the right question.
> 
> I think I am trying to take your admission that Chapter 5 is only
> eight pages long and use that as the basis for it not needing to
> be a separate Chapter, just for Pass-1 instructions, in the first
> place.
> 
> To look at this in another way, at the end of the "old" Chapter 5
> you had something you could tar up, move around and use
> elsewhere but at the end the proposed Chapter 5, you have nothing
> (OK, not nothing) that is of any use without the Chapter 6 Pass-2
> bits, so why split them out into separate Chapters.
> 
> 
> Can you not have an introduction to a Part in DocBook? If so then
> those three non-build sections would go in there and the Pass1 and
> Pass2
> sections would just go back to being in a Chapter 5, with the chroot
> build
> in Chapter 6.
> 
> 
> Note also that whilst Part III has the title
> 
> Building the LFS Cross Toolchain and Temporary Tools
> 
> it actually contains three Chapters
> 
> Cross-Toolchain
> Temporary Tools
> Chroot/Additional Tools
> 
> so why doesn't the third of those chapters get an honourable
> mention in the Part title?
> 
> Maybe the last of thoise three should have a nod to the "Temporary"
> so
> 
> Cross-Toolchain
> Base Temporary Tools
> Chroot/Additional Temporary Tools
> 
> or similar.
> 
> Then again, using the BLFS Java "bridgehead" example as one way to do
> things
> 
> III Constructing the Temporary, Cross-Compiled, Build Environment
> 
> Chapter 5 Building the Cross-Compiled Tools
> 
> Bridgehead:Intro to Cross-Compilng
> 
> 5.1 Toolchain Technical Notes
> 5. 2 General Compilation Instructions
> 
> Bridgehead: Compiling a Cross-Toolchain
> 
> 5.3 onwards: Pass -1 sections
> 
> Bridgehead: Cross Compiling Temporary Tools
> 
> Tools for Pass-2 sections
> Pass-2 sections
> 
> Chapter 6: Creating the host-isolated (chroot) Build Environment
> 
> ...
> 
> IV. Building the LFS System
> 
> Or something like that anyway.
> 
> Hoping that's useful,
> Kevin

Please tell us what you think of:
http://www.linuxfromscratch.org/~pierre/lfs-svn/index.html
(I've not bee able to remove the latin numbering in the "Preliminary
material")

Personally, I do not care much about small chapters: chapter 3 is only
three pages...

I really think the the building of temporary tools is done in three
stages.

Regards
Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Using Chapter 7's Util-linux for su (for a short time)

[Pierre Labastie via lfs-dev]

On Wed, 2020-06-17 at 20:28 +0800, Kevin Buckley via lfs-dev wrote:
> With the recent reorganisation comes the addition of Util-linux into
> the
> chroot environment.
> 
> The instructions there follow the standard LFS practice of disabling
> various
> utilities from Util-linux , including the su utility, which gets
> provided by the
> Shadow package.
> 
> As someone who builds LFS following the "More Control and Package
> Management" hint, I'm in the habit of building Shadow in the chroot,
> so
> as to then be able to "su" to the PkgUser accounts for each
> package.in
> the LFS system
> 
> Can anyone think of any reasons why I would not be able to use the su
> from Util-linux, until such time as Chapter 8's (nearly typed Chapter
> 6's
> there) Shadow get's built?

Actually, We have looked at it (you may have noticed that we needed to
add a regular user for tests), and the conclusion is that util-linux's
"su" uses linux-PAM. So, a no-go for lFS.

On the other hand, nothing prevents you from building shadow at the
beginning of chapter 8, as you seem to have been doing already (except
the chapter number was 6).

Now, I see a problem: all the packages that are rebuilt in chapter
eight are installed in place of the corresponding temporary package. If
you install the final package as a regular user, it won't be able to
replace the temp package that has been installed as root... I must
confess we have not thought of the pkguser method when redesigning the
book.

Maybe, what can be done is use the pkguser method starting in chapter
6, that is, instead of building as user lfs, build as the package user,
just taking care that the package user environment is set as the lfs
user environment.

It would require to install shadow (for su) at the beginning of chapter
7, just after entering chroot. Normally host's "su" is usable in
chapter 6.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Mon, 2020-06-15 at 19:28 +0800, Kevin Buckley via lfs-dev wrote:
> On Mon, 15 Jun 2020 at 18:34, Pierre Labastie via lfs-dev
>  wrote:
> > OTOH, personally, I like meson/ninja. I wish it were used more
> > often.
> > They have nothing to do with systemd.
> 
> For some reason, I had thought that there was a package in the SysD
> build that was "so new" that it had never had an autotools system but
> had been tooled, from the start, with meson/ninja, hence them being
> required.
> 
> > > Given that LFS used to start from the view that one only built
> > > what was needed to build the LFS-system, and never warming
> > > to the systemd camp fire, i've always felt Ninja and Meson to be
> > > a kind of feature-creep and so was wondering if that could be
> > > made more explicit, so that people could see that Ninja and Meson
> > > could happily be left out until BLFS.
> > > (Though there's no getting away from them there: more's the
> > > pity!)
> > 
> > OTOH, personally, I like meson/ninja. I wish it were used more
> > often.
> > They have nothing to do with systemd,
> 
> In that case, I withdraw the suggestion and apologise for any
> confusion
> that suggestion might cause for anyone else reading this thread.
> 

*I* have to apologize for not being clear: yes, meson/ninja are needed
by sysd and not needed in the sysv book. I just meant they are not part
of the systemd package (and that I liked them, which is just my
personal taste). I think xry111 suggestion might be a good compromise.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Mon, 2020-06-15 at 15:09 +0800, Kevin Buckley via lfs-dev wrote:
> On Sat, 13 Jun 2020 at 20:46, Bruce Dubbs via lfs-dev
>  wrote:
> > In the last few weeks, the LFS editors have been working on a major
> > overhaul of LFS.  This work can be reviewed at
> > 
> > http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/
> > 
> 
> Was there an SVN reference (branch) to pull the sources from?

svn://svn.linuxfromscratch.org/LFS/branches/cross2

> 
> > We welcome comments and criticisms large and small.
> > 
> >-- Bruce
> 
> These comments (or maybe criticisms - your interpretation: your
> rules)
> based on a very quick speed read: please take that into consideration
> when deciding.
> 
> I'd like to see the "cross-compiling 101" sections, so
> 
> Introduction
> Toolchain Technical Notes
> General Compilation Instructions

> in "chapter" 5, separated out from the package build sections there.
> 
> Appreciate they would make for a very small introductory chapter
> but it somehow feels wrong as it is.

The main problem to me is not this, but that technical considerations
are scattered throughout the first chapters, mainly chapter 2 and
chapter 5. OTOH, "General Compilation Instructions" should really be
very close to the beginning of the "real" work. People tend to jump to
it, and not read this important section already, so if it is in another
chapter, that will not help...

> 
> Not sure if I'd favour the Pass1 and Pass2 sections all being within
> the same chapter or not though, or how one would entitle a chapter
> that just contained just those five package builds, plus yet another
> Introduction.
> 
> I am also aware that Ninja and Meson are still only "required" for
> the SystemD version, but that LFS has decided to build packages
> in the SysV revision with them, even though all required packages
> can still be built using an Autotools-based approach.
> (I 'm sure that claim is soon to be rendered invalid though?)

autotools themselves are only needed because we do autoreconf in
coreutils. And this is because of the i18n patch...

> 
> I appreciate there's a perception that the SysV and SysD books
> should align as much as possible, indeed I've even got some
> packages re-ordered on the basis of that view, but I'm less
> convinced that the SystemD tail should wag the LFS dog.

OTOH, personally, I like meson/ninja. I wish it were used more often.
They have nothing to do with systemd.

> 
> Given that LFS used to start from the view that one only built
> what was needed to build the LFS-system, and never warming
> to the systemd camp fire, i've always felt Ninja and Meson to be
> a kind of feature-creep and so was wondering if that could be
> made more explicit, so that people could see that Ninja and Meson
> could happily be left out until BLFS.
> (Though there's no getting away from them there: more's the pity!)

OTOH, personally, I like meson/ninja. I wish it were used more often.
They have nothing to do with systemd, and those "configure" scripts are
just bloated, slow, and do not scale up on many cores.

> 
> Then again, I could make the same claim for Intltool and a
> couple of other packages related to it.
> 
> Looking forwards to trying it out though,
> Kevin

Thanks for contributing.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Sun, 2020-06-14 at 15:15 +0200, Pierre Labastie via lfs-dev wrote:
> 
> I am currently testing whether moving iana-etc before gcc may allow
> tests to pass, as reported by Joe Locash. If so, I'll commit it.
> 

Hmm, having iana-etc does not change anything to the
"22_locale/time_get/..." failures, and there is still one
failure in experimental/net/internet/resolver, even with a real
/etc/host installed!

Waiting for more evidence that it is useful to move the packages
around...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] ANNOUNCEMENT - Major Proposed Changes to LFS

[Pierre Labastie via lfs-dev]

On Sat, 2020-06-13 at 15:10 +0100, spiky via lfs-dev wrote:
> On 13/06/2020 13:46, Bruce Dubbs via lfs-dev wrote:
> > In the last few weeks, the LFS editors have been working on a
> > major 
> > overhaul of LFS.  This work can be reviewed at
> > 
> > http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/
> > 
> > The elements of building LFS using cross compiling techniques have 
> > changed a lot.  The old Chapter 5 has been split into three
> > chapters 
> > that have a different focus for each chapter.
> > 
> > Some of the advantages include not requiring a /tools symlink on
> > the 
> > host system and not requiring a lot of hackish symlinks when
> > starting 
> > the final build system.
> > 
> > In addition, a lot of work was done to minimize the number of test 
> > failures in the different packages.
> > 
> > Finally, every page in the new book was reviewed and textual
> > updates 
> > made to clarify different elements of the LFS process.
> > 
> > We welcome comments and criticisms large and small.
> > 
> >   -- Bruce
> 
> Hi
> 
> I have biult using the systemd version a few times since Pierre 
> mentioned it, The only part I find awkward is the backup, "only
> because 
> it's different" i used to be able to just cp -a tools somewhere, But 
> otherwise it works fine, Just different to regular builders.
> 

I've done intensive testing with ICA lately, and the results are as
good as before.

On systems which have CONFIG_AUDIT enabled in the kernel, perl thinks
that the user who builds it is "tester". That may seem surprising, but
since it only appears in the documentation system, it has no
consequence. Not tested, but I think it is the same in the regular
(development) book with the recent changes.

I am currently testing whether moving iana-etc before gcc may allow
tests to pass, as reported by Joe Locash. If so, I'll commit it.

Pierre

PS: in relation to another thread: making an arm build would require
just a few changes to the main build (at least on aarch64). Of course,
one of the hard parts would be choosing the correct bootloader and
kernel options: there are zillion of arm architectures!

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future for LFS

[Pierre Labastie via lfs-dev]

On Sat, 2020-06-13 at 00:05 -0500, Bruce Dubbs via lfs-dev wrote:
> On 6/12/20 10:00 PM, William Harrington via lfs-dev wrote:
> > Greetings,
> > 
> > I’ve noticed that LFS is only targeting i386 and AMD64.  The is a
> > great hunger for LFS to support ARM. Many have wished for the
> > support. What is keeping LFS from supporting ARM?
> > 
> > What I have seen while reading forums and IRC chat, LFS should be
> > supporting ARM.
> > Why is the book only targeting I386 and X86_64 and nothing else?
> > 
> > There are ma y LFS users who have attempted to contribute their
> > knowledge.
> > Why is LFS not using g one archs ?
> 
> You know, of course, that LFS is done 100% by volunteers.  It's not
> just 
> time, but also money.  We pay of hosting and our development
> hardware.
> 
> For my part, I spend well over 40 hours a week on LFS and work on it
> 7 
> days a week.  I don't have time to add another architecture.  I
> doubt 
> the other editors do either.
> 
> If you want to clone LFS for an ARM architecture, then you are more
> than 
> welcome.  We can even let it be hosted on the LFS servers.
> 

Personally, I do not have the hardware for that. I do not have the time
either, and this is why: 
the problem is not lfs, but blfs. There are around 750 packages in
there. If those packages are all updated twice a year (some have much
more frequent updates...), it makes 4 updates per day, 7/7.
Updates mean: get the source, check it is right (gpg signatures,
whatever), update size and md5. Build and test it, analyze and restart
when something gets wrong (very often, the instructions for one version
have to be changed for the next one), measure and update sbu and disk
usage, do a "DESTDIR" install to check new installed or not installed
files and dirs. Update the xml, publish. Also check that dependent
packages still build (not always done, actually, but it means that full
builds of blfs must be run from times to times). Most of this cannot be
automated because of the diversity in upstream sources and build
systems.

Now, the cross-chap5 branch is much easier to adapt to arm. So you
might see unofficial forks... But not from me sorry. My experience with
a VM was too painful (time, again).

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

On Mon, 2020-05-25 at 22:17 +0100, Ken Moffat via lfs-dev wrote:
> On Mon, May 25, 2020 at 05:20:44PM +0200, Pierre Labastie via lfs-dev 
> wrote:
> > On Mon, 2020-05-25 at 16:14 +0200, Pierre Labastie via lfs-dev
> > wrote:
> > > Now this has been done with /dev/pts bind mounted. Let's try with
> > > /dev/pts mounted normally...
> > > 
> > > Same, that is: no /dev/tty error...
> > > 
> > 
> > But binding /dev/pts removes the failure in coreutils tests

Various fixes discussed in this thread have been committed at r11859.
I've used Bruce's sed for automake (with an added "s" :)
I've added an upstream patch for gold (found by D. Reno), which allows
to recover the:
===
Testsuite summary for gold 0.1
===
# TOTAL: 276
# PASS:  276

that had disappeared when switching to gcc 10.

I have changed mounting /dev/pts as --bind. We should allow the
possibility to revert if we find out that some distros have gid!=5 for
tty. It removes one failure in coreutils tests.

I have changed the way to su to nobody for bash. There are still test
failures (diff output), due to the fact that nobody does not have r/w
access to /dev/stdin, /dev/stdout, or /dev/stderr. I think there are
two possibilities to fix this:
a - create a regular user, and use su - for this user
b - use util-linux' su with the -P option (allows to allocate a private
terminal for the su session, which is not possible with shadow's
su)

I have added the locale-archive symlink (in Creating symlinks and
files). Note that this page is becoming complicated, and is much
simplified in the cross-chap5 branch.

Note that I have also updated vim to 8.2.0814, since all testers have
used that version.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev wrote:
> Hi,
> Here are test results from a jhalfs run:
> trunk book
> $LFS is a subdirectory of $HOME, not a mount point (shouldn't be
> important, but who knows)
> with changes:
> -  added a link:
>/tools/lib/locale/locale-archive ->
>   /usr/lib/locale/locale-archive
> -  vim version: 8.2.0814
> 
> ---
> binutils: gcctestdir/collect-ld: error: plugin_common_test_2.o:
>  multiple definition of 'c5'
>   gcctestdir/collect-ld: plugin_common_test_1.o.syms:
>  previous definition here
>   gcctestdir/collect-ld: error: plugin_common_test_2.o:
>  multiple definition of 'c1'
>   gcctestdir/collect-ld: plugin_common_test_1.o.syms:
>  previous definition here
>   gcctestdir/collect-ld: error: plugin_common_test_2.o:
>  multiple definition of 'c4'
>  make[6]: *** [Makefile:9003: plugin_test_10] Error 1
>   in gold tests (whose result are very uneasy to understand :/)
>   an d other errors I do not understand
>  readelf: Error: the PHDR segment is not covered by a LOAD
> segment
>  make[6]: *** [Makefile:8954: plugin_test_6] Error 1
>  make[6]: Leaving directory '/sources/binutils-
> 2.34/build/gold/testsuite'
>  make[5]: *** [Makefile:7727: check-am] Error 2
>  make[5]: Leaving directory '/sources/binutils-
> 2.34/build/gold/testsuite'
>  make[4]: *** [Makefile:7731: check] Error 2
>  make[4]: Leaving directory '/sources/binutils-
> 2.34/build/gold/testsuite'
> 

For this one, renodr has found an upstream fix, which cures the
problem.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

On Mon, 2020-05-25 at 16:14 +0200, Pierre Labastie via lfs-dev wrote:
> 
> Now this has been done with /dev/pts bind mounted. Let's try with
> /dev/pts mounted normally...
> 
> Same, that is: no /dev/tty error...
> 

But binding /dev/pts removes the failure in coreutils tests
Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

Top posting because it is a long post, and the TL;DR is:

Use:
su nobody -s /bin/bash << EOF
  command
EOF

instead of:
su nobody -s /bin/bash -c "command"

Now is the story with bottom posting...


On Sun, 2020-05-24 at 22:21 +0100, Ken Moffat via lfs-dev wrote:
> On Sun, May 24, 2020 at 10:16:34PM +0100, Ken Moffat wrote:
> > On Sun, May 24, 2020 at 07:35:10PM +0200, Pierre Labastie via lfs-
> > dev wrote:
> > > On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev
> > > wrote:
> > > > Hi,
> > > > Here are test results from a jhalfs run:
> > > > [...
> > > 
> > > about vim test
> > > > ===
> > > > [...]
> > > > ---
> > > > vim: stops at test1:
> > > >  test1 FAILED - terminal size must be 80x24 or larger
> > > >  Executed: 0 Tests
> > > >   Skipped: 0 Tests
> > > >Failed: 0 Tests
> > > 
> > > For some reason, my gnome terminal had 80 columns and 23 lines.
> > > Vim tests do not run if the number of lines is less than 24!
> > > and the number of columns is less than 80.
> > > 
> > > Note that the in chroot the command "tty" returns "Not a tty",
> > > and that
> > > may explains some test failures, specially with bash tests
> > > 
> > > Pierre
> > > 
> > Hi Pierre,
> > 
> > thanks for looking at this.
> > 
> > One of the reasons why my build has taken so long is that I'm
> > trying
> > to look at every failign testsuite, to see if there is a way around
> > it.  For some things (e.g. iproute) we just say it doesn't work -
> > at
> > the moment I don't know if it can work (needs libmna, and then it
> > wants sudo for rmmod), but in chroot I'm going to suggest it SHOULD
> > NOT be run and therefore its missing deps can be ignored.
> > 
> > And in particular, I had not realised that tty fails like that.  It
> > does indeed explain apparent failures in the bash tests.  I wonder
> > if, instead of mounting dev/pts we should bind it ?
> 
> Or, better - because we bind /mnt/lfs/dev to /dev, perhaps NOT mount
> /dev/pts in chroot ?  In theory, that should give us what is on the
> host in /dev/pts, but then the group may be wrong if the host uses a
> different group from LFS.

Tried both:
- not mounting /dev/pts at all: /dev/pts is empty, so I guess it is
unusable
- binding /dev/pts: works, and "tty" returns /dev/fd/0 (progress)

Unfortunately, bash tests still fail because of:
/dev/tty: No such device or address

Now, tried the following (this is what is performed by one of the
tests:
-
(lfs chroot)...# test -t 0 http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev wrote:
> Hi,
> Here are test results from a jhalfs run:
> [...

about vim test
> ===
> [...]
> ---
> vim: stops at test1:
>  test1 FAILED - terminal size must be 80x24 or larger
>  Executed: 0 Tests
>   Skipped: 0 Tests
>Failed: 0 Tests

For some reason, my gnome terminal had 80 columns and 23 lines.
Vim tests do not run if the number of lines is less than 24!
and the number of columns is less than 80.

Note that the in chroot the command "tty" returns "Not a tty", and that
may explains some test failures, specially with bash tests

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] test results with locale-archive symlink and vim-8.2.0814 (trunk book)

[Pierre Labastie via lfs-dev]

Hi,
Here are test results from a jhalfs run:
trunk book
$LFS is a subdirectory of $HOME, not a mount point (shouldn't be
important, but who knows)
with changes:
-  added a link:
   /tools/lib/locale/locale-archive ->
  /usr/lib/locale/locale-archive
-  vim version: 8.2.0814

There are a number of issues which seem related to the fact that the
script does not own a tty. Specially, it seems vim tests are not run!

Also, it seems gold has some issue with gcc 10.
Otherwise, a lot of test suites have very good results.
Not that "no failure" in the following is not the output of the test,
but my own summary of longer uninteresting output.

Also, I apologize if some of the issues have been reported before. I
haven't checked mails.
===
glibc:
  Summary of test results:
   5177 PASS
 23 UNSUPPORTED
 17 XFAIL
  2 XPASS
---
zlib: pass
---
xz: All 9 tests passed
---
file: pass (apparently)
---
m4: no failure
---
bc: All bc tests passed.
---
binutils: gcctestdir/collect-ld: error: plugin_common_test_2.o:
 multiple definition of 'c5'
  gcctestdir/collect-ld: plugin_common_test_1.o.syms:
 previous definition here
  gcctestdir/collect-ld: error: plugin_common_test_2.o:
 multiple definition of 'c1'
  gcctestdir/collect-ld: plugin_common_test_1.o.syms:
 previous definition here
  gcctestdir/collect-ld: error: plugin_common_test_2.o:
 multiple definition of 'c4'
 make[6]: *** [Makefile:9003: plugin_test_10] Error 1
  in gold tests (whose result are very uneasy to understand :/)
  an d other errors I do not understand
 readelf: Error: the PHDR segment is not covered by a LOAD segment
 make[6]: *** [Makefile:8954: plugin_test_6] Error 1
 make[6]: Leaving directory '/sources/binutils-
2.34/build/gold/testsuite'
 make[5]: *** [Makefile:7727: check-am] Error 2
 make[5]: Leaving directory '/sources/binutils-
2.34/build/gold/testsuite'
 make[4]: *** [Makefile:7731: check] Error 2
 make[4]: Leaving directory '/sources/binutils-
2.34/build/gold/testsuite'
  Otherwise:
=== binutils Summary ===

  # of expected passes267
  # of unsupported tests  2
=== gas Summary ===

  # of expected passes1358
=== ld Summary ===

  # of expected passes2409
  # of expected failures  57
  # of untested testcases 1
  # of unsupported tests  39
---
gmp:  197 PASS
---
mpfr: 180 PASS
---
mpc:   67 PASS
---
attr:   2 PASS
---
libcap: no failure
---
gcc: 
=== g++ tests ===

=== g++ Summary ===

  # of expected passes  192178
  # of expected failures709
  # of unsupported tests7882

=== gcc tests ===

=== gcc Summary ===

  # of expected passes  149098
  # of expected failures694
  # of unsupported tests2220

=== libatomic tests ===

=== libatomic Summary ===

  # of expected passes  54
=== libgomp tests ===

=== libgomp Summary ===

  # of expected passes  2642
  # of expected failures2
  # of unsupported tests294
=== libitm tests ===

=== libitm Summary ===

  # of expected passes  42
  # of expected failures3
  # of unsupported tests1
=== libstdc++ tests ===

  FAIL: 22_locale/time_get/get_time/char/2.cc execution test
  FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
  FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution
test
  FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
  FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution
test
  FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution
test
  FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test
  FAIL: experimental/net/internet/resolver/ops/reverse.cc execution
test

=== libstdc++ Summary ===

  # of expected passes14098
  # of unexpected failures8
  # of expected failures  93
  # of unsupported tests  390
---
pkg-config: All 30 tests passed
---
sed: no failure
---
gettext: 4 tests results, no FAIL, no ERROR
---
bison: no failure
---
flex: no failure
---
grep: no failure
---
bash: several failures. One recurrent error message:
  line xxx: /dev/tty: No such device or address
---

Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?

[Pierre Labastie via lfs-dev]

On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev
wrote:
> Hey there,
> 
> I'd like to inquire about the actual need for the /toolchain symlink
> on the host system.
> 
> Apparently, failure to create this link causes
> configure/build/linking
> problems starting from Chapter's 5 libstdc++ with errors in the form
> of failure to perform sanity checks (mostly because cpp's (gcc -E)
> include paths are wrong), ld not finding crt1.o, crti.o, and so on...
> 
> I'm not really sure why this link is required though. I understand
> that it's currently a must to build LFS (apparently not much
> explanation is provided to how GCC/Binutils searching/configuring
> works with regards to directory layout,so we need to cover for
> $LFS/tools and /tools with the latter being silently used in some
> places to make the toolchain build; by silently I mean automatically
> appended to $LFS without knowing when/where so it won't error out),
> but wouldn't specifying correct flags when configuring GCC, binutils
> and Glibc remove the need for such symlink?
> 
> These errors can be evaded by closely examining
> `--with-native-system-header-dir` and `--with-sysroot` starting from
> GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command
> to "../../lib" based on where ld is searching), along with
> `--with-lib-path` in binutils pass 1.
> 
> I'm curious to hear your thoughts on the matter.
> 
> Thanks for your time and effort.

Chapter 5 is not the problem: we could change to $LFS/tools everywhere
we have /tools. But then, when going to chapter 6, some search paths
would contain $LFS/tools, that we do not have in chroot. That's the
reason to have the link and use it in chapter 5.


Note, we could maybe create /mnt/lfs in chroot, and have:
/mnt/lfs/tools->/tools in chroot.
Never tried.

Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] CFLAGS in fixing up for gcc-10.

[Pierre Labastie via lfs-dev]

On Thu, 2020-05-14 at 10:57 +0300, Firas Khalil Khana via lfs-dev
wrote:
> 
> That being said, and based on my testings, I believe `gdbm` is the
> only package that won't build with that flag and needs `-fcommon`
> explicitly specified in CFLAGS.
> 
> A couple of packages that might not work with the default
> `-fno-common` include `pkg-config`, `coreutils`, `man-db` and `zlib`.

Hmm, answered here because the thread was here. Should have been on
blfs-dev mailing list. There are many more packages affected by this in
blfs...

The lfs book is already fixed in trunk. We have used patches or sed
everywhere, except in systemd, where upstream has not published enough
patches yet.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] CFLAGS in fixing up for gcc-10.

[Pierre Labastie via lfs-dev]

On Thu, 2020-05-14 at 14:33 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-13 23:46 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 5/13/20 11:33 PM, Ken Moffat via lfs-dev wrote:
> > > I notice that in some places people have overridden any existing
> > > CFLAGS when adding -fcommon.  In most places, for those of us who
> > > care the fix is obvious (CFLAGS="$CFLAGS -fcommon").  One or two
> > > packages will turn out to be more painful.
> > > 
> > > The first I've found is freeglut, where the book uses
> > >-DCMAKE_C_FLAGS=-fcommon
> > > 
> > > For people without any existing CFLAGS, that does the right thing
> > > and respects the -O3 etc from specifying a Release build (seen by
> > > using 'make VERBOSE=1') but for people who have extra flags such
> > > as
> > > "-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
> > > 
> > > I'd assumed I could add
> > >   -DCMAKE_CFLAGS="$CFLAGS -fcommon"
> > > 
> > > but if I do that, cmake tells me that CFLAGS was not referenced.
> > > 
> > > In this case, I am getting the right results (testing on a gcc-9
> > > system) with:
> > > 
> > > CFLAGS="${CFLAGS} -fcommon" \
> > > cmake -DCMAKE_INSTALL_PREFIX=/usr  \
> > >-DCMAKE_BUILD_TYPE=Release   \
> > >-DFREEGLUT_BUILD_DEMOS=OFF   \
> > >-DFREEGLUT_BUILD_STATIC_LIBS=OFF \
> > >-Wno-dev ..
> > > 
> > > Can I ask people to at least *consider* not trashing a user's
> > > specified CFLAGS ?
> > 
> > Yes, we can do that, but right now we are trying to just get
> > everything 
> > to build with gcc10.  When that is done, we can probably review and
> > do 
> > 'grep -r CFLAGS; in the book's xml top and do the right thing where
> > we 
> > have had to make changes.
> > 
> > Also as new package releases address gcc10, we can probably remove
> > a lot 
> > of the CFLAGS entries that we've been making.
> 
> I don't like -fcommon.  It's actually changing C semantics.  The
> correct thing
> to do is to fix the code (like what we do for gdbm in LFS).
> 
> Though we can simply add this workaround for now...

Bruce: rather "grep -- -fcommon ..."
Xi Ruoyao: you are right that C semantics is to have "extern" in header
files, which may be included in several .c files, and that variables
should be defined once and only once in some .c file. But...

-fcommon was the default until gcc 9 included. So the packages which do
not compile with -fno-common have been tested against -fcommon
(silently, with former versions of gcc), while the patches have been
less tested.

Furthermore, adding patches for all the packages which fail to compile
is much more work than just a CFLAGS addition. Since this work will be
obsoleted as soon as next release or so, it is tempting not to spend
too much time on it...

I agree, I'm lazy!

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] CFLAGS in fixing up for gcc-10.

[Pierre Labastie via lfs-dev]

On Thu, 2020-05-14 at 05:33 +0100, Ken Moffat via lfs-dev wrote:
> I notice that in some places people have overridden any existing
> CFLAGS when adding -fcommon.  In most places, for those of us who
> care the fix is obvious (CFLAGS="$CFLAGS -fcommon").  One or two
> packages will turn out to be more painful.
> 
> The first I've found is freeglut, where the book uses
>   -DCMAKE_C_FLAGS=-fcommon
> 
> For people without any existing CFLAGS, that does the right thing
> and respects the -O3 etc from specifying a Release build (seen by
> using 'make VERBOSE=1') but for people who have extra flags such as
> "-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
> 
> I'd assumed I could add
>  -DCMAKE_CFLAGS="$CFLAGS -fcommon"
> 
> but if I do that, cmake tells me that CFLAGS was not referenced.
> 
> In this case, I am getting the right results (testing on a gcc-9
> system) with:
> 
> CFLAGS="${CFLAGS} -fcommon" \
> cmake -DCMAKE_INSTALL_PREFIX=/usr  \
>   -DCMAKE_BUILD_TYPE=Release   \
>   -DFREEGLUT_BUILD_DEMOS=OFF   \
>   -DFREEGLUT_BUILD_STATIC_LIBS=OFF \
>   -Wno-dev ..
> 
> Can I ask people to at least *consider* not trashing a user's
> specified CFLAGS ?

Sorry about that Ken. As you noted in another post, cmake semantics is
not always easy to understand. I thought that doing like that was
preserving user's CFLAGS... And for some reason I thought CFLAGS where
not passed when doing the above (CFLAGS in the environment).

Will fix the book, and add "$CFLAGS" before -fcommon at other places I
have put them.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] proposal: some improvements to LFS book

[Pierre Labastie via lfs-dev]

On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> I just redone LFS build for GCC-10.1.0.  I proposed several
> improvements during
> the process:
> 
> At first, some changes suggested by Firas:
> 
> 1. Remove bzip2 in Chap. 5.  No other changes needed.

decreases the total number of SBUs by 0.1 :) why not, though

> 
> 2. Remove ncurses in Chap. 5.  Move Chap. 6 readline after ncurses to
> satisify
> it.
> Notes:
> (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
> module we don't
> need.
> (2) We moved readline before bc to satisify GNU bc, but now Gavin's
> bc doesn't
> need readline.

good point

> (3) It slightly reduces the functionality of Chap. 5 bash.  Long
> command lines
> won't be wrapped automatically anymore.

It does much more than that if the terminfo database is not installed:
no backspace (more exactly, backspace outputs only a space forward...)
left and right arrows not functional.
In short, no way to correct a typo

can be Ok if scripting though

> 
> 3. Remove flex in Chap. 5.  Move Chap. 6 flex before Binutils so
> `ranlib` and
> `ar` can link to libfl.so.  It seems bison test suite does not
> depends on flex
> any more.

bison chapter 6 will be built after flex anyway, if we do the above, so
whether it depends on it or not is not important.

> 
> However Firas' other suggestions are proved to be impossible.  Glibc
> requires
> bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
> so all of
> them need to stay in Chap. 5.  Util-linux can't be removed from Chap.
> 5 due to
> its circular dependency with systemd/eudev.
> 
> And:
> 
> 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
> use zstd to
> compress LTO stream.

definitely to be done, independently on the other points.

> 
> 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd.  It
> seems
> unneeded now.
> 
> 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make.  It is unneeded now.
> 
> 7. Add:
> 
>   mkdir /tools/lib/locale
>   localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
> 
> into Chap. 5 Glibc.  It will satisfy Chap. 6 man-db test.

Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
archive

allows also all bison tests to pass

> 
> 8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
> "Cleaning
> up" section.

Independent on the other points and should be done for sure.

> 
> Are they OK to be committed into trunk?

I'd say point 2 shouldn't not be committed, or only with some tweak of
the terminfo database...

among the other points:

- 4 and 8 should be done for sure.
- I've not tested 5 and 6, but I guess you have tested them, so go for
them too
- I'd rather use the link for point 7 (less instructions in chap 5
glibc). This is just one more line in "creating essentials symlinks and
files".
- I'm not sure about point 3: building flex only once is tempting, but
can the tests be run, and is flex the same as if rebuilt at the end of
chap 6?
- Point 1 improves only marginally the build time, but why not?

Regards
Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] gcc-10 and stack protector in kernel

[Pierre Labastie via lfs-dev]

Sorry if this has already been reported. With gcc 10 and kernel 5.6.11,
I get:
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
in: start_secondary+0x169/0x170

at early boot.
this has been reported upstream [1], who made a complicated patch,
mainly consisting of comments. It seems it occurs only when
CONFIG_STACKPROTECTOR_STRONG=y. I do not know which kernel will have
it. 5.6.12 doesn't.

Two possibilities: remove the STACK_PROTECTOR_STRONG config, or apply
this sed:

sed -e '/cpu_startup/a asm("");' -i arch/x86/kernel/smpboot.c

which does not fix xen kernel, but does everything else the patch does.

Pierre

[1] end of a long thread on lkml: 
https://lore.kernel.org/lkml/158798746828.28353.6010675315553653459.tip-bot2@tip-bot2/

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] gcc-10 breaks systemd-245

[Pierre Labastie via lfs-dev]

On Sat, 2020-05-09 at 09:22 -0500, Brendan L via lfs-dev wrote:
> > As a workaround, I've added: CFLAGS=-Wno-format-overflow to the
> > meson
> > command. It may not be the best thing to do to pass CFLAGS, but I
> > do
> > not know enough of meson to do better...
> > 
> 
> The preferred way with meson to define CFLAGS and CXXFLAGS is with
> "-Dc_args=" and  "-Dcpp_args="

Thanks a lot, will do.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] gcc-10 breaks systemd-245

[Pierre Labastie via lfs-dev]

I get:
--
[418/1741] Compiling C object 'src/core/2ac6ece@@core@sta/path.c.o'
FAILED: src/core/2ac6ece@@core@sta/path.c.o 
cc -Isrc/core/2ac6ece@@core@sta -Isrc/core -I../src/core -Isrc/basic
-I../src/basic -Isrc/boot -I../src/boot -Isrc/shared -I../src/shared
-Isrc/systemd -I../src/systemd -Isrc/journal -I../src/journal
-Isrc/journal-remote -I../src/journal-remote -Isrc/nspawn
-I../src/nspawn -Isrc/resolve -I../src/resolve -Isrc/timesync
-I../src/timesync -I../src/time-wait-sync -Isrc/login -I../src/login
-Isrc/udev -I../src/udev -Isrc/libudev -I../src/libudev -Isrc/shutdown
-I../src/shutdown -I../src/libsystemd/sd-bus -I../src/libsystemd/sd-
device -I../src/libsystemd/sd-event -I../src/libsystemd/sd-hwdb
-I../src/libsystemd/sd-id128 -I../src/libsystemd/sd-netlink
-I../src/libsystemd/sd-network -I../src/libsystemd/sd-resolve
-Isrc/libsystemd-network -I../src/libsystemd-network -I. -I..
-I/usr/include/libmount -I/usr/include/blkid -fdiagnostics-color=always 
-pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu99 -O3
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-
result -Wno-format-signedness -Werror=undef -Wlogical-op -Wmissing-
include-dirs -Wold-style-definition -Wpointer-arith -Winit-self
-Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes
-Werror=implicit-function-declaration -Werror=missing-declarations
-Werror=return-type -Werror=incompatible-pointer-types -Werror=format=2
-Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wimplicit-
fallthrough=5 -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-
strings -Werror=overflow -Werror=shift-count-overflow -Werror=shift-
overflow=2 -Wdate-time -Wnested-externs -Wno-error=nonnull -Wno-maybe-
uninitialized -ffast-math -fno-common -fdiagnostics-show-option -fno-
strict-aliasing -fvisibility=hidden -fstack-protector -fstack-
protector-strong --param=ssp-buffer-size=4 -ffunction-sections -fdata-
sections -Werror=shadow -include config.h -fPIC -pthread -MD -MQ
'src/core/2ac6ece@@core@sta/path.c.o' -MF 'src/core/2ac6ece@@core@sta/p
ath.c.o.d' -o 'src/core/2ac6ece@@core@sta/path.c.o' -c
../src/core/path.c
../src/core/path.c: In function ‘path_serialize’:
../src/core/path.c:616:24: error: ‘%s’ directive argument is null [-
Werror=format-overflow=]
  616 | (void) serialize_item_format(f, "path-spec",
"%s %i %s",
  |^~~~
~
  617
|  path_type_to_string(s-
>type),
  |  ~~
~~~
  618 |  s-
>previous_exists,
  |  ~~
~
  619 |  s->path);
  |  
In function ‘path_spec_dump’,
inlined from ‘path_dump’ at ../src/core/path.c:392:17:
../src/core/path.c:226:9: error: ‘%s’ directive argument is null [-
Werror=format-overflow=]
  226 | fprintf(f,
  | ^~
  227 | "%s%s: %s\n",
  | ~
  228 | prefix,
  | ~~~
  229 | path_type_to_string(s->type),
  | ~
  230 | s->path);
  | 
cc1: some warnings being treated as errors
--
This has been reported upstream:
https://github.com/systemd/systemd/issues/14691

But this particular part does not seem to have been fixed.

As a workaround, I've added: CFLAGS=-Wno-format-overflow to the meson
command. It may not be the best thing to do to pass CFLAGS, but I do
not know enough of meson to do better...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Pierre Labastie via lfs-dev]

On Mon, 2020-05-04 at 06:51 +0100, Ken Moffat via lfs-dev wrote:
> On Mon, May 04, 2020 at 12:51:34PM +0800, Xi Ruoyao via lfs-dev
> wrote:
> > > Doesn't really explain why man-db has sometimes failed, but
> > > passed
> > > other times (for various builders).  Maybe there is something
> > > else
> > > there.
> > 
> > In sysv book, there was no util-linux in chap. 5 (until Pierre
> > added them to fix
> > problems found by ICA).  So the tests using util-linux tools would
> > be skipped.
> 
> That make sense.  I'll blame Pierre ! ;-)
> 
> No, obviously I won't blame Pierre, but this is still very much work
> in progress.
> 

I did blame myself :)
http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-May/073696.html

so could it be that packages built in chap 5 look for locales in
/tools/share?

A few experiments (the "toto" command is just to have bash printing an
error message):
root [ / ]# echo $LC_ALL
fr_FR.UTF-8
root [ / ]# exec /bin/bash
root [ / ]# toto
bash: toto : commande introuvable

root [ / ]# exec /tools/bin/bash
bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8)
root [ / ]# echo $LC_ALL
fr_FR.UTF-8
root [ / ]# toto
bash: toto: command not found

So /tools/bin/bash is not seeking locales in /usr/lib/locale/locale-
archive (where compiled locales are stored, man localedef for details).

I guess it is the same for col from util-linux.

One possible fix is:
mkdir /tools/lib/locale
ln -s /usr/lib/locale/locale-archive /tools/lib/locale

with that:
root [ / ]# export LC_ALL=fr_FR.UTF-8
root [ / ]# exec /tools/bin/bash
root [ / ]# toto
bash: toto : commande introuvable

Another tweak needed because of a separate /tools...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Modified build of LFS using pure cross-compilation and sysroot

[Pierre Labastie via lfs-dev]

On Sat, 2020-05-02 at 19:02 +0200, Thomas Trepl via lfs-dev wrote:
> Am Freitag, den 01.05.2020, 15:53 +0200 schrieb Pierre Labastie via
> lfs-dev:
> > Hi,
> > 
> > I propose a new way to build LFS, which removes the need for the
> > /tools
> > symlink, and decreases the number of tweaks needed when building
> > gcc.
> > 
> > The current build builds a cross-compiler in pass1, and uses it as
> > a
> > native compiler in pass2. This needs to use a non standard
> > directory
> > (/tools) to host the toolchain and insulate it from the build
> > machine.
> > 
> > The modified build uses the cross compiler to cross compile
> > packages
> > that need themselves to be rebuilt, thus insulating them
> > automatically
> > from the host, without the need for a non standard directory
> > layout.
> > Chroot is entered as soon as possible, and the remaining chapter 5
> > packages are built in chroot.
> 
> Wow, quite interesting!  I'd vote to have a deeper look to that
> mechanism.
> 
> > This is WIP: the text must be improved at several places, bison and
> > flex may be moved to after chroot (to be tested). But the commands
> > seem
> > to produce an acceptable system, with almost clean ICA.
> > 
> > You can view it at [1], only for sys V since I have not tested
> > systemd
> > yet (I do not expect many changes).
> > 
> > There are pros and cons compared to the current method:
> > 
> >   pros: no /tools symlink, no need to tweak gcc sources, no need to
> > build twice ld in binutils-pass2, no need to readjust the toolchain
> > after chapter 6 glibc, no need to tweak the gcc specs, no need to
> > reinstall kernel headers in chapter 6.
> 
> The less we have to tweak core packages (and gcc is for sure one of
> them), the better. I would see that as a great benefit.
> 
> >   cons: chroot is entered in the middle of chapter 5 (maybe chapter
> > 5
> > should be split), the debug sections of several packages reference
> > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2
> > needs "enable-shared".
> Ok, here is the "traditional" separation of Chapter 5 (as run with
> host tools) and the Chapter 6 (running previously built tools in
> chroot) in danger. But at the end, its just a naming issue. 
> 
> With your method we have kinda Chapter 5a building core tools, a
> Chapter 5b building toolchain for full build using 5a in chroot and
> finally the well-known Chapter 6.
> 
> For the cost of entering the chroot in the middle of chap5, we got
> rid
> of the adjusting which sometimes causes trouble for newbies. This
> knot
> is simply untied.
> 
> > Another pro, not tried, is that some simple packages built in
> > chapter 5
> > may be built only once if testing them is not required.
> > 
> > Comments and suggestions for improvement (there's a lot of room for
> > improvement) welcome.
> 
> Its great!  I'd see that as a big evolution step in the LFS
> ecosystem.
> 
> I see a restart to continue not more complicated as it is now. When
> continuing an interrupted build in chap5 now, user has also to
> prepare
> the environment carefully. Same in new chapter 5a so no change here.
> Continuing in chap 5b, only need to reenter the chroot, this not any
> different to want currently has to be done while it comes a few steps
> earlier.
> 
> Maybe the new Chapter 5 should end with leaving the chroot
> environment
> with unmounting the virtFS. It could be a proper end to chap5 as at
> this stage, a backup of the system might be recommended (as a hint
> for
> the user).
> The new chapter 6 should then reenter the chroot env again. IMHO this
> would make the differentiation of chap5 and 6 a bit easier.
> 

Thanks to all who answered. The book source is now available at:
svn co svn://svn.linuxfromscratch.org/LFS/branches/cross-chap5

Some fixes have been done, but there is still a problem with ncurses:
the terminfo database is not built because it needs tic from the build
host, and we do not require it. Then using the terminal in chroot is
painful (no backspace nor line editing capability).

One simple fix would be to require tic on the build host with version
greater than or equal to 6.0, and remove the --disable-db-install
switch.

Another fix would be to first build ncurses for the build host (no
cross-compile), and use the just built tic (there are configure
switches for that).

Another fix is to cheat and use the cross-compiled tic on the build
host (but it's not pure cross compilation anymore).

Pierre



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Test failure in man-db

[Pierre Labastie via lfs-dev]

On Sun, 2020-05-03 at 01:18 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/2/20 11:44 PM, Ken Moffat via lfs-dev wrote:
> > On Sun, May 03, 2020 at 12:02:12PM +0800, Xi Ruoyao via lfs-dev
> > wrote:
> > > On 2020-05-03 04:18 +0100, Ken Moffat via lfs-dev wrote:
> > > > I'm building with LFS as at 25th April.  My previous build was
> > > > in
> > > > early April, and I think this is the first time I've seen a
> > > > failure
> > > > in the man-db tests.  With man-db-2.9.1 :
> > > > 
> > > > FAIL: man-missing-locales
> > > > 
> > > > and src/tests/test-suite.log has:
> > > > 
> > > > FAIL: man-missing-locales
> > > > =
> > > > 
> > > > col: failed on line 319: Invalid or incomplete multibyte or
> > > > wide character
> > > > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col
> > > > -b -p -x | sed
> > > > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > > >FAIL: missing locales
> > > > FAIL man-missing-locales (exit status: 1)
> > > > 
> > > > Given that things have changed since my previous build, is
> > > > anyone
> > > > else seeing this ?  I suspect the error might be "mine, all
> > > > mine",
> > > > so I'm reluctant to add to the noise by reporting iti upstream
> > > > unless it really is common.  Looking at my glibc log I did
> > > > apparently install the en_US.UTF-8 locale.
> > > 
> > > I've seen this many times (almost each time I built LFS).
> > 
> > I'm surprised - as I just replied to Doug, this is the first time
> > this has hit me.  Will take a look on the completed system, to see
> > if it breaks there.
> 
> The man-db test failure may be due to some other package that we've 
> added since 9.1. However
> 
> http://www.linuxfromscratch.org/lfs/build-logs/9.1/i7-5820K/test-logs/135-man-db-2.9.0
> 
> shows no failures.  But the systemd log Doug uploaded (i5-6600k)
> does 
> show it.  AFAICT, the differences are minor.  In my sysv system 
> util-linux was not built in Chapter 5, but it is built in Doug's
> systemd 
> build.
> 
> I will also note that the sysv instructions have the extra
> configuration 
> items:
> 
> --with-systemdtmpfilesdir=   \
> --with-systemdsystemunitdir=
> 
> and there is a sed in systemd version that is not in the sysv
> version. 
> A cursory look at those changes doesn't indicate to me an issue that 
> would cause  the man-missing-locales test to fail.
> 
> If someone really wants to track this down, look at
> src/tests/testlib.sh 
> and src/tests/man-missing-locales.  They are relatively short sh
> scripts.

The log alludes to "col" which is an util-linux program. And util-linux 
has been in chapter 5 for a while in the systemd book, while it has
been added recently to the SysV book (to "clean" ICA). So it really
looks like a candidate to explain the failure!

Note also that on a completed system, the tests pass, so my guess is
that it works after util-linux is installed in chapter 6 (to be
verified).

Now the call to col is internal to "man", so it may take some time to
find how to print more explicit errors...

Will try to remove util-linux and run the tests on a completed system.

Pierre


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] is the HELP2MAN trick still needed for flex?

[Pierre Labastie via lfs-dev]

Now that flex is in chapter 5 and that it is built without the trick,
it can be seen that flex.1 man page is installed anyway.

Is there something more that the HELP2MAN trick would allow?

If not, I suggest to remove it. It just confuses things

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Modified build of LFS using pure cross-compilation and sysroot

[Pierre Labastie via lfs-dev]

On Sat, 2020-05-02 at 11:19 +1000, James B via lfs-dev wrote:
> 
> > 
> > [1] http://www.linuxfromscratch.org/~pierre/lfs-modified/index.html
> 
> If you can produce a single HTML version of this, that would be good
> because it would be easier to archive for future reference. This idea
> has its merits regardless its inclusion into the main LFS book.
> 

nochunk and sysd versions added. Thanks for comments and support

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Modified build of LFS using pure cross-compilation and sysroot

[Pierre Labastie via lfs-dev]

On Sat, 2020-05-02 at 10:55 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-01 20:51 -0500, Douglas R. Reno via lfs-dev wrote:
> > On 5/1/20 8:53 AM, Pierre Labastie via lfs-dev wrote:
> > >cons: chroot is entered in the middle of chapter 5 (maybe
> > > chapter 5
> > > should be split), the debug sections of several packages
> > > reference
> > > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-
> > > pass2
> > > needs "enable-shared".
> > 
> > The debug information being broken is a major dealbreaker for me. I
> > use 
> > the debug information from these packages semi-frequently and not
> > having 
> > that at my disposal would make things a lot tougher for me.
> 
> Hopefully we can fix the debug info with some -ffile-prefix-map
> parameter in
> $CC.

Yes, This can be done, but it is messy:
LFS_DIR=/usr/lib/gcc/$(uname -m)-lfs-linux-gnu
DIR=/usr/lib/gcc/$(../scripts/config.guess)
../configure --prefix=/usr\
 CC="gcc -ffile-prefix-map=$LFS_DIR=$DIR" blah

But actually, the fact that the debug sections reference a wrong source
location does not prevent using gdb in this case: the sources
referenced are private gcc headers, which don't generate code, so are not used 
by gdb.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Modified build of LFS using pure cross-compilation and sysroot

[Pierre Labastie via lfs-dev]

Hi,

I propose a new way to build LFS, which removes the need for the /tools
symlink, and decreases the number of tweaks needed when building gcc.

The current build builds a cross-compiler in pass1, and uses it as a
native compiler in pass2. This needs to use a non standard directory
(/tools) to host the toolchain and insulate it from the build machine.

The modified build uses the cross compiler to cross compile packages
that need themselves to be rebuilt, thus insulating them automatically
from the host, without the need for a non standard directory layout.
Chroot is entered as soon as possible, and the remaining chapter 5
packages are built in chroot.

This is WIP: the text must be improved at several places, bison and
flex may be moved to after chroot (to be tested). But the commands seem
to produce an acceptable system, with almost clean ICA.

You can view it at [1], only for sys V since I have not tested systemd
yet (I do not expect many changes).

There are pros and cons compared to the current method:

  pros: no /tools symlink, no need to tweak gcc sources, no need to
build twice ld in binutils-pass2, no need to readjust the toolchain
after chapter 6 glibc, no need to tweak the gcc specs, no need to
reinstall kernel headers in chapter 6.

  cons: chroot is entered in the middle of chapter 5 (maybe chapter 5
should be split), the debug sections of several packages reference
x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2
needs "enable-shared".

Another pro, not tried, is that some simple packages built in chapter 5
may be built only once if testing them is not required.

Comments and suggestions for improvement (there's a lot of room for
improvement) welcome.

Regards
Pierre


[1] http://www.linuxfromscratch.org/~pierre/lfs-modified/index.html

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] SVN-20200423 Iana-ETC is obsolete (suggestion?)

[Pierre Labastie via lfs-dev]

On Sun, 2020-04-26 at 09:30 -0400, Jean-Marc Pigeon via lfs-dev wrote:
> Hello,
> 
> 
> Working with my (LFS based) server, I got a trouble
> with /etc/services (iana port definition), as (just an example)
> port 953 (rndc) is not defined.
> 
> The LFS /etc/services (extracted from iana-etc-2.30.tar.bz2)
> is obviously obsolete (2008).
> 
> The last iana-etc (services port definition) is available
> from
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> 
> last updated 2020-04-07
> 
> Problem: that file is an RFC/splitted like, not straigth forward
> to convert to /etc/services file.
> 
> Questions:
> 1) Should not LFS use an updated /etc/service definition?

We could try to use the one from below. But there are fairly frequent
updates...

> 2) could somebody know about an up to date service-names-port-number
>in tar format location?

Not tried, but found https://github.com/Mic92/iana-etc/releases

Maybe it is just the xml, and then there is a need to run the update.py
tool (below) on it

> 3) Is there a "tools" to convert that kind of RFC/human format to
>a plain services file format?

Again, not tried:
https://github.com/Mic92/iana-etc/blob/master/update.py

converts the .xml file to /etc/services

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] e2fsprog depends optionally on udev

[Pierre Labastie via lfs-dev]

On Sat, 2020-04-18 at 21:03 +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Apr 03, 2020 at 07:15:28PM +0100, Ken Moffat via lfs-dev
> wrote:
> > On Fri, Apr 03, 2020 at 07:33:08PM +0200, Pierre Labastie via lfs-
> > dev wrote:
> > > I've reinstated the ICA system in jhalfs, in order to test the
> > > builds
> > > with the sysroot/cross-compile system.
> > > 
> > > For those who haven't folowed lfs in the 200x years, ICA
> > > (iterative
> > > comparison analysis) is a way to rebuild the system with itself,
> > > and
> > > compare the results. There used to be another system, "farce",
> > > written
> > > by Ken, which had to be removed from jhalfs for licensing
> > > problems. I
> > > think this sytem is still accessible at Ken's home on 
> > > www.linuxfromscratch.org.
> > > 
> > 
> > Unfortunately, the problem with maintaining farce was that what I
> > think was randomization of positioning in gcc caused the content of
> > the binaries to not match.
> > 
> > I put farce under GPLv2 which is too restrictive for Pierre.
> > 
> > > Anyway, I found that e2fsprogs was linked against libudev on the
> > > second
> > > build, and not on the first. The reason is that eudev is uilt
> > > after
> > > eudev.
> > > 
> > > Maybe we could exchange eudev and e2fsprogs?
> > > 
> > > Of course, this is only valid for sysv. I do not know (yet) what
> > > happens on systemd.
> > > 
> > > Pierre
> > > 
> > 
> > Sounds like a good idea.
> > 
> > ĸen
> 
> At this point, I'd like to pass my congratulations to Pierre for
> what he has established - understanding the final details of why
> some things which had used to be ok now produced different code was
> not something I ever managed.  I see Pierre has documented objdump
> invocations in the tickets.
> 

Thanks Ken. I hope you've seen that I was completely wrong with this
message. It's not e2fsprog, but util-linux, which links against libudev
on second pass. I thought I had sent a message about that, but I cannot
find it now. Anyway, the ticket(s) is(now are) correct, which just
means I have not found something wrong in them yet. But some of them
are not solved...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] chapter 6 readline slightly incorrect

[Pierre Labastie via lfs-dev]

On Thu, 2020-04-09 at 12:18 -0500, Bruce Dubbs via lfs-dev wrote:
> On 4/9/20 11:38 AM, Tadeus Prastowo via lfs-dev wrote:
> > On Thu, Apr 9, 2020 at 9:12 AM Pierre Labastie <
> > pierre.labas...@neuf.fr> wrote:
> > > On Wed, 2020-04-08 at 23:27 +0200, Tadeus Prastowo wrote:
> > > > Perhaps you need to check with a program that links to
> > > > libreadline
> > > > using the --if-needed option.
> > > > 
> > > 
> > > I think you are right and this needs some testing.
> > > Actually, this is my question: are there still packages using --
> > > if-
> > > needed? Not in lfs for sure. I'll do a full build of blfs to make
> > > sure.
> > > 
> > > If you can point me to a package using that (even outside blfs),
> > > please
> > > do.
> > 
> > The OP of the first link mentions `GNU parted-1.8.6'.  I haven't
> > checked whether the latest version of parted still does it.
> > 
> > > OTOH, is -L/tools/lib needed? I hate the idea of putting a
> > > reference to
> > > /tools in final lfs builds. I have to try, but I think that just
> > > using
> > > SHLIB_LIBS=-lncursesw will add
> > > libncursesw to the list of needed ibraries, without resolving the
> > > above
> > > names at static link time (having them resolved at dynamic link
> > > time
> > > instead).
> > 
> > AFAIK, -L will not embed anything in the resulting shared library.
> 
> Correct.  It just tells the linker where to look.  rpath does embed
> the location of dynamic libraries.

Ok, thanks. After doing a jhalfs build with and without the SHLIB_LIBS
setting, I see that some results in util-linux configure are different.
This is not a big deal, since readline is marginally used in util-
linux, but it shows that other packages might behave differently
without the setting.

So the only thing to do is to add --with-curses, so that the .pc file
is correctly generated, and keep the SHLIB_LIBS=... setting.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] util-linux depends optionally on udev

[Pierre Labastie via lfs-dev]

Changed the subject to reflect what is really going on...

On Thu, 2020-04-09 at 11:56 +0200, Pierre Labastie via lfs-dev wrote:
> 
[...]
> Sometimes I wonder why I assume something without checking! It
> happens
> to me too often that it then proves wrong!
> 
> Here it is: I've discovered that findmnt was linked to libudev after
> second pass, and not after thefirst pass. But why have I assumed that
> findmnt was coming from e2fsprog
> 
> e2fsprog does not even test libudev, and the only reference to udev
> is
> a reference to udev's rules directory needed for e2scrub.
> 
> findmnt is from util-linux, and that one links to libudev if it is
> present. So eudev should be before util-linux, but I have to test
> that
> nothing depends on util-linux in eudev...
> 
> Trying a build with eudev before util-linux ATM.
> 

No joy, eudev depends on libblkid (more exactly, cdrom_id, ata_id,
xxx_id, ...). So this is a circular dependency, and I'd say that having
functional xxx_id is more important than having libudev in findmnt (but
this depends on use cases, I guess).

Anyway, I think I'll try a new build adding util-linux in chap 5, as we
do in systemd book. That might be the best solution.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] e2fsprog depends optionally on udev

[Pierre Labastie via lfs-dev]

On Sun, 2020-04-05 at 09:37 +, DJ Lucas via lfs-dev wrote:
> On April 3, 2020 2:17:29 PM CDT, Pierre Labastie via lfs-dev <
> lfs-dev@lists.linuxfromscratch.org> wrote:
> > On Fri, 2020-04-03 at 13:27 -0500, Bruce Dubbs via lfs-dev wrote:
> > > On 4/3/20 12:33 PM, Pierre Labastie via lfs-dev wrote:
> > > > I've reinstated the ICA system in jhalfs, in order to test the
> > > > builds
> > > > with the sysroot/cross-compile system.
> > > > 
> 
> This is really cool, and necessary from time to time (as you've
> discovered).
> 
> > > > For those who haven't folowed lfs in the 200x years, ICA
> > > > (iterative
> > > > comparison analysis) is a way to rebuild the system with
> > > > itself,
> > > > and
> > > > compare the results. There used to be another system, "farce",
> > > > written
> > > > by Ken, which had to be removed from jhalfs for licensing
> > > > problems.
> > > > I
> > > > think this sytem is still accessible at Ken's home on
> > > > www.linuxfromscratch.org.
> > > > 
> > > > Anyway, I found that e2fsprogs was linked against libudev on
> > > > the
> > > > second
> > > > build, and not on the first. The reason is that eudev is uilt
> > > > after
> > > > eudev.
> > > > 
> > > > Maybe we could exchange eudev and e2fsprogs?
> > > 
> > > How about just moving eudev to between util-linux and e2fsprogs?
> 
> When reordering here, be careful not to adjust systemd
> (udev/systemd). It's all a few years of fuzzy, but the interaction of
> those three packages was a bit of a nightmare when merging the two
> books. IIRC, that was what prompted the extra partial build of util-
> linux in chapter 5 for systemd, so we could keep the build order
> roughly the same across the two books (difference in systemd deemed
> acceptable because systemd gets reinstalled early in BLFS - and I'm
> pretty sure this will still show up if you run ICA on systemd). I
> want to say something to do with a disk geometry library that got
> moved from e2fsprogs to util-linux (or maybe vice versa), but it is
> all so long ago, I'm unsure.
> 
> Anyway, if running a comparison build, it'll reveal itself, so it's
> really cool that this is working again!
> 
> --DJ
> 

Sometimes I wonder why I assume something without checking! It happens
to me too often that it then proves wrong!

Here it is: I've discovered that findmnt was linked to libudev after
second pass, and not after thefirst pass. But why have I assumed that
findmnt was coming from e2fsprog

e2fsprog does not even test libudev, and the only reference to udev is
a reference to udev's rules directory needed for e2scrub.

findmnt is from util-linux, and that one links to libudev if it is
present. So eudev should be before util-linux, but I have to test that
nothing depends on util-linux in eudev...

Trying a build with eudev before util-linux ATM.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Another issue revealed by ICA

[Pierre Labastie via lfs-dev]

When doing ICA,
I see that login, expiry, and su differ between first pass and next.
Using objdump, I see that the files from first pass reference
/bin/passwd, while the files from the next pass reference
/usr/bin/passwd. Note that passwd is installed in /usr/bin (and not
moved to /bin afterwards), so the files from the first pass reference a
non existent file.

The reason is that configure uses default /bin/passwd if it does not
find /usr/bin/passwd. Since passwd is not yet installed when first
building shadow, the default is used, while on the second build,
/usr/bin/passwd exists and is used.

Looking at the source code, passwd is forked by the login program when
a password has expired, so that the user can enter a new password. This
fails when shadow has been built as in chapter 6. So for machines
where:
- shadow has not been recompiled (for pam or for upgrading)
- password expiration is set for a user
Then this user cannot login anymore when the password has expired, and
cannot change her/his password.

As an illustration, log as root to a fresh lfs, then:
# useradd -m somebody
# passwd somebody
Changing password for somebody
Enter the new password (minimum 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password:
Re-enter new password:
passwd: password changed.
# passwd -e somebody # makes the pasword expired
passwd: password expiry information changed.
# login pierre
Password:
Your password has expired; Choose a new password.
Can't execute /bin/passwd: No such file or directory

(there is a password entered at the three prompts above, but it
does not show up)

The workaround is to:
touch /usr/bin/passwd
before running configure

Pierre




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] chapter 6 readline slightly incorrect

[Pierre Labastie via lfs-dev]

On Wed, 2020-04-08 at 14:06 +0200, Tadeus Prastowo via lfs-dev wrote:
> Hello Pierre,
> 
> On Wed, Apr 8, 2020 at 11:55 AM Pierre Labastie via lfs-dev
>  wrote:
> > Hi,
> > 
> > We say that SHLIB_LIBS="-L/tools/lib -lncursesw" is needed to force
> > Readline to link against the libncursesw library. But:
> > 1) Even if readline uses the tremcap functions, it does not link
> > against any library containing it (see the INSTALL file in source).
> > 2) This switch had not effect to the only file where termcap
> > appears:
> > readline.pc, which has "Requires.private: termcap" anyway.
> > 
> > Packages using the Requires.private field may therefore be fooled
> > by this, but I have found none until now, so the problem is
> > unlikely
> > to occur.
> > 
> > Anyway, there is a configure switch, --with-curses, which allows
> > generating the correct readline.pc.
> > 
> > So we should use this switch, and remove the SHLIB_LIBS settings,
> > which
> > do not bring anything.
> 
> Have you taken into account the following messages for the reason to
> have SHLIB_LIBS="-L/LFS-tools/lib -lncursesw"?
> 
> https://lists.gnu.org/archive/html/bug-readline/2007-03/msg3.html
> and its reply
> https://lists.gnu.org/archive/html/bug-readline/2007-03/msg5.html
> 
> https://lists.gnu.org/archive/html/bug-readline/2014-04/msg7.html
> and its reply
> https://lists.gnu.org/archive/html/bug-readline/2014-04/msg00024.html
> 
> 

No I didn't (before you pointed to them), but I think I came to the
exact same conclusion as the person who replied in both threads: that
could have been anticipated, since I used the present (readline-8.0)
doc, specially INSTALL, which most likely has been written by the same
person.
I have tried everything I said. Linking both libraries completes OK
even if SHLIB_LIBS is not passed. And adding --with-curses just changes
the readline.pc file to reference ncurses instead of termcap.

But I do not intend to commit this until I have done a complete rebuild
of lfs, with ICA to make sure this problem has gone away.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] chapter 6 readline slightly incorrect

[Pierre Labastie via lfs-dev]

Hi,

We say that SHLIB_LIBS="-L/tools/lib -lncursesw" is needed to force
Readline to link against the libncursesw library. But:
1) Even if readline uses the tremcap functions, it does not link
against any library containing it (see the INSTALL file in source).
2) This switch had not effect to the only file where termcap appears:
readline.pc, which has "Requires.private: termcap" anyway.

Packages using the Requires.private field may therefore be fooled
by this, but I have found none until now, so the problem is unlikely
to occur.

Anyway, there is a configure switch, --with-curses, which allows
generating the correct readline.pc.

So we should use this switch, and remove the SHLIB_LIBS settings, which
do not bring anything.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] x86_64-bit dynamic linker location

[Pierre Labastie via lfs-dev]

On Tue, 2020-04-07 at 21:37 -1000, Dean Takemori via lfs-dev wrote:
> For x86_64 builds, LFS patches gcc to set the default directory name
> for 64-bit libraries to “lib” instead of “lib64” (eg in chapter
> 5.5.1, 5.10.1 and 6.25.1) by patching gcc/config/i386/t-linux64
> 
> But the location of the dynamic linker is left in /lib64, meaning a
> “stub directory” /lib64 ends up being created and then a
> compatibility symlink added in chapter 6.9.1
> 
> 
> Is there any reason to not additionally patch gcc and glibc to have
> the x86-64 dynamic linker reside in /lib?
> 
> 
> Tested with glibc-2.31 and gcc-9.3.0 in the final system (not tested
> in the temporary system) : there are three locations to patch; No
> /lib64 ends up being created and the compatibility symlink no longer
> required.
> 
> gcc:
>   sed -i -e '/GLIBC_DYNAMIC_LINKER64/s/lib64/lib/'
> gcc/config/i386/linux64.h
> 
> glibc:
>   sed -i 's/lib64/lib/' sysdeps/unix/sysv/linux/x86_64/ldconfig.h
>   sed -i '/RTLDLIST/s/264/2/' sysdeps/unix/sysv/linux/x86_64/ldd-
> rewrite.sed
> 
> It’s possible this has some side-effects or issues with some BLFS
> packages (particularly programming/debugging tools), but I have not
> run into any in my usage.

I think the main problem is if one installs a binary package. Most
likely, it will look for /lib64/ld-linux-x86-64.so.2, or even
/lib64/ld-lsb-x86-64.so.3 according to LSB.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] e2fsprog depends optionally on udev

[Pierre Labastie via lfs-dev]

On Fri, 2020-04-03 at 13:27 -0500, Bruce Dubbs via lfs-dev wrote:
> On 4/3/20 12:33 PM, Pierre Labastie via lfs-dev wrote:
> > I've reinstated the ICA system in jhalfs, in order to test the
> > builds
> > with the sysroot/cross-compile system.
> > 
> > For those who haven't folowed lfs in the 200x years, ICA (iterative
> > comparison analysis) is a way to rebuild the system with itself,
> > and
> > compare the results. There used to be another system, "farce",
> > written
> > by Ken, which had to be removed from jhalfs for licensing problems.
> > I
> > think this sytem is still accessible at Ken's home on
> > www.linuxfromscratch.org.
> > 
> > Anyway, I found that e2fsprogs was linked against libudev on the
> > second
> > build, and not on the first. The reason is that eudev is uilt after
> > eudev.
> > 
> > Maybe we could exchange eudev and e2fsprogs?
> 
> How about just moving eudev to between util-linux and e2fsprogs?
> 
> 

Yes, I don't even know why I wrote "exchange"...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] e2fsprog depends optionally on udev

[Pierre Labastie via lfs-dev]

I've reinstated the ICA system in jhalfs, in order to test the builds
with the sysroot/cross-compile system.

For those who haven't folowed lfs in the 200x years, ICA (iterative
comparison analysis) is a way to rebuild the system with itself, and
compare the results. There used to be another system, "farce", written
by Ken, which had to be removed from jhalfs for licensing problems. I
think this sytem is still accessible at Ken's home on 
www.linuxfromscratch.org.

Anyway, I found that e2fsprogs was linked against libudev on the second
build, and not on the first. The reason is that eudev is uilt after
eudev.

Maybe we could exchange eudev and e2fsprogs?

Of course, this is only valid for sysv. I do not know (yet) what
happens on systemd.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Linux kernel policy

[Pierre Labastie via lfs-dev]

On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote:
> > We have almost always updated the linux kernel to the "mainline" 
> > release.  We do skip intermediate releases though because of the 
> > frequency of releases.
> > 
> > For instance, today is the 90th day of the year, but there have
> > been 
> > about 34 releases.  The first release of the year was 5.4.8.  There
> > is a 
> > little overlap there because 5.4 is a longterm release.  In any
> > case 
> > there have been 13 releases for 5.5 since February 1st (14 if you
> > count 
> > 5.6).
> > 
> > I would like to propose keeping the kernel at the most recent long
> > term 
> > support (LTS) version for the book.  Users can, of course, use
> > whatever 
> > version they want.
> > 
> > What do you think?
> > 
> >-- Bruee
> 
> For 5.4 LTS, we got 21 releases in this year, and 12 releases since
> Feb. 1st. 
> No significant improvement.  LTS meaning continuing maintenance so
> we'll still
> get one release for each severe bug (even if it's a bug in a strange
> server
> motherboard).
> 
> I think we can just hold on kernel 5.x.0 for the development book
> unless there
> is a bug making it unusable.  (There is already a note telling the
> audience to
> use latest 5.x.y.)  And, we should update to latest 5.x.y before 9.2.
> 

I'd say that what we have (update the kernel to latest when updating
other parts of the book) is not so bad, except we should refrain to
update to whatever.0 versions. It's not because the maintainers have
done some mistake once (modifying a driver between the last rc and the
release IIUC), that they always will do, but we should consider
whatever.0 versions are still "development" (not only for kernel
actually).

With this policy, chances are that the first version we include in a
5.x series is higher than 5.x.1.

Anyway, since LTS gets updated very often too, there is no much gain in
using LTS.

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] sysklogd

[Pierre Labastie via lfs-dev]

On Sat, 2020-03-28 at 17:59 +0100, Pierre Labastie via lfs-dev wrote:
> On Sat, 2020-03-28 at 10:04 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 3/28/20 7:48 AM, Pierre Labastie via lfs-dev wrote:
> > > On Sat, 2020-03-28 at 00:04 -1000, Dean Takemori via lfs-dev
> > > wrote:
> > > > The version of sysklogd that LFS uses (1.5.1 - from
> > > > https://www.infodrom.org/projects/sysklogd/) has not been
> > > > updated
> > > > in
> > > > over 5 years (late 2014).
> > > > 
> > > > There is a successor project with active development (
> > > > https://github.com/troglobit/sysklogd), which consolidates
> > > > klogd
> > > > into
> > > > syslogd, adds remote logging, autotools build system among many
> > > > other
> > > > things.
> > > > 
> > > > With standard
> > > > ./configure --prefix=/usr —-sbindir=/sbin --
> > > > sysconfdir=/etc --
> > > > localstatedir=/var
> > > > make
> > > > make install
> > > > 
> > > > and the attached boot script patch, this new version has been
> > > > working
> > > > quite well in my setup
> > > > 
> > > > Should LFS mgirate over?
> > > +1, but maybe wait for things to settle: there have been 7
> > > releases
> > > in
> > > 5 months...
> > 
> > What are the real advantages?  What we have now seems to work
> > pretty 
> > well.  Both syslogd and klogd are in the same package and build in
> > less 
> > than 0.1 SBU (one second in my log).  There is only one bootscript
> > that 
> > launches both daemons.  syslogd handles remote logging.
> > 
> > We do have a couple of minor seds, but I am reluctant to change a 
> > working package just because something is newer.
> 
> From what I see on the site, it implements a new rfc for syslog, and
> fix a couple of glitches with remote logging. I think the code itself
> is pk, because it has a long history on {free,net}bsd. It is the
> porting to autotools, which needs still some polishing...

s/pk/ok/ I cannot type

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] sysklogd

[Pierre Labastie via lfs-dev]

On Sat, 2020-03-28 at 10:04 -0500, Bruce Dubbs via lfs-dev wrote:
> On 3/28/20 7:48 AM, Pierre Labastie via lfs-dev wrote:
> > On Sat, 2020-03-28 at 00:04 -1000, Dean Takemori via lfs-dev wrote:
> > > The version of sysklogd that LFS uses (1.5.1 - from
> > > https://www.infodrom.org/projects/sysklogd/) has not been updated
> > > in
> > > over 5 years (late 2014).
> > > 
> > > There is a successor project with active development (
> > > https://github.com/troglobit/sysklogd), which consolidates klogd
> > > into
> > > syslogd, adds remote logging, autotools build system among many
> > > other
> > > things.
> > > 
> > > With standard
> > >   ./configure --prefix=/usr —-sbindir=/sbin --sysconfdir=/etc --
> > > localstatedir=/var
> > >   make
> > >   make install
> > > 
> > > and the attached boot script patch, this new version has been
> > > working
> > > quite well in my setup
> > > 
> > > Should LFS mgirate over?
> > +1, but maybe wait for things to settle: there have been 7 releases
> > in
> > 5 months...
> 
> What are the real advantages?  What we have now seems to work pretty 
> well.  Both syslogd and klogd are in the same package and build in
> less 
> than 0.1 SBU (one second in my log).  There is only one bootscript
> that 
> launches both daemons.  syslogd handles remote logging.
> 
> We do have a couple of minor seds, but I am reluctant to change a 
> working package just because something is newer.

From what I see on the site, it implements a new rfc for syslog, and
fix a couple of glitches with remote logging. I think the code itself
is pk, because it has a long history on {free,net}bsd. It is the
porting to autotools, which needs still some polishing...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] sysklogd

[Pierre Labastie via lfs-dev]

On Sat, 2020-03-28 at 00:04 -1000, Dean Takemori via lfs-dev wrote:
> The version of sysklogd that LFS uses (1.5.1 - from 
> https://www.infodrom.org/projects/sysklogd/) has not been updated in
> over 5 years (late 2014).
> 
> There is a successor project with active development (
> https://github.com/troglobit/sysklogd), which consolidates klogd into
> syslogd, adds remote logging, autotools build system among many other
> things.
> 
> With standard 
>   ./configure --prefix=/usr —-sbindir=/sbin --sysconfdir=/etc --
> localstatedir=/var
>   make
>   make install
> 
> and the attached boot script patch, this new version has been working
> quite well in my setup
> 
> Should LFS mgirate over?
> 
> 

+1, but maybe wait for things to settle: there have been 7 releases in
5 months...

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Differences in package description texts beween LFS and BLFS

[Pierre Labastie via lfs-dev]

Le 23/03/2020 à 10:12, Kevin Buckley via lfs-dev a écrit :
> On Mon, 23 Mar 2020 at 16:59, Pierre Labastie via lfs-dev
>  wrote:
> 
>>
>> I think blfs adds a level of details so that users can decide whether they
>> want to build the package or not. In LFS, they have to build the package 
>> anyway.
>>
>> Look at the descriptions for Python too.
> 
> They DO appear to be the same though? Well, give or take the "it" and the 
> "This"
> at the start of the second sentence ?
> 
> 6.51. Python-3.8.1
> 
> The Python 3 package contains the Python development environment. It
> is useful for object-oriented programming, writing scripts,
> prototyping large programs or developing entire applications.
> 
> Python-3.8.1
> 
> Introduction to Python 3
> 
> The Python 3 package contains the Python development environment. This
> is useful for object-oriented programming, writing scripts,
> prototyping large programs or developing entire applications.
> 
> 
> I hear your "level of detail" claim but would counter with a "consistency" 
> one !
> 

Hmmm, Looks like I did not look at the right place for Python lfs... Having
the introduction in the title header mislead me (I haven't seen it at first).

Anyway, as you know, lfs/blfs has a 20 years history, with dozens of
contributors. Editing policy has had some variations. Certainly, a lot of
explanations need some overhaul (I've been browsing through the whole blfs
book while formatting the xml, and I can tell you that some explanations are
outdated or could be better done). But now the lfs/blfs team is very small. So
I do not think it is possible to do anything good besides updating build
instructions (the most important).

TL;DR: there is no reason for the differences, but if you send some patches,
I'm sure we'll be happy to include them.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Differences in package description texts beween LFS and BLFS

[Pierre Labastie via lfs-dev]

Le 23/03/2020 à 09:53, Kevin Buckley via lfs-dev a écrit :
> Because I decided to build the three packges from LFS's Chapter 5
> that don't get built in Chapter 6, despite the builder having had to
> download the sources for Chapter 5, I noticed:
> 
> 5.11. Tcl-8.6.10
> 
> The Tcl package contains the Tool Command Language.
> 
> 
> 5.12. Expect-5.45.4
> 
> The Expect package contains a program for carrying out scripted
> dialogues with other interactive programs.
> 
> 5.13. DejaGNU-1.6.2
> 
> The DejaGNU package contains a framework for testing other programs.
> 
> 
> but then, over in BLFS-land:
> 
> 
> Tcl-8.6.10
> 
> The Tcl package contains the Tool Command Language, a robust
> general-purpose scripting language.
> 
> 
> Expect-5.45.4
> 
> It contains tools for automating interactive applications such as
> telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect is also useful for
> testing these same applications as well as easing all sorts of tasks
> that are prohibitively difficult with anything else.
> 
> DejaGnu-1.6.2
> 
> DejaGnu is a framework for running test suites on GNU tools. It is
> written in expect, which uses Tcl (Tool command language).
> 
> 
> and was wondeing why the descriptive text wasn't synchronised for
> common packages.
> 

I think blfs adds a level of details so that users can decide whether they
want to build the package or not. In LFS, they have to build the package anyway.

Look at the descriptions for Python too.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Ordering of Chapter 5 GGC Pass2 required external packages stanza

[Pierre Labastie via lfs-dev]

Le 14/03/2020 à 10:44, Pierre Labastie via lfs-dev a écrit :
> Le 14/03/2020 à 09:56, Kevin Buckley via lfs-dev a écrit :
>> I note, because my PkgUser Book has explicit sections for
>> unpacking the sources that the vanilla book doesn't, that,
>> in Chapter 5 GGC Pass2, the order of actions prior to the
>> creation of the build directory is:
>>
>>
>> Unpack the required external packages
>> Change the location of GCC's default dynamic linker
>> On x86_64 hosts, set the default directory name for 64-bit libraries to 
>> “lib”:
>>
>>
>> however in GCC Pass 2, it's
>>
>>
>> Create a full version of an internal header
>> Change the location of GCC's default dynamic linker
>> On x86_64 hosts, set the default directory name for 64-bit libraries to 
>> “lib”:
>> Unpack the required external packages
>> Fix a problem introduced by Glibc-2.31
>>
>>
>> Is there any reason why the required external packages can't be
>> the first thing done in GCC Pass 2 as well?
>>
>> Indeed, is there any reason why the ordering in GCC Pass 2
>> couldn't be:
>>
>>
>> Unpack the required external packages
>> Change the location of GCC's default dynamic linker
>> On x86_64 hosts, set the default directory name for 64-bit libraries to 
>> “lib”:
>> Create a full version of an internal header
>> Fix a problem introduced by Glibc-2.31
>>
>> where the two actions not carried out in Pass 1 come
>> after the three that are?
>>
>> Given that there is no reason given for the change in order,
>> I think this would make the two Pass sections more similar,
>> thereby highlighting the differences in the second pass.
>>
>>
>> I could also suggest that the wording
>>
>> Now fix a problem introduced by Glibc-2.31:
>>
>> might be more explict about why, so perhaps:
>>
>> Now fix a problem introduced by the Glibc-2.31 we have just built:
>>
> 
> I think this will be removed in next version of gcc (as mentioned by Xi
> Ruoyao), but in case this isn't, and glibc-2.32 appears, the problem will
> still have been introduced by glibc-2.31, which we won't be building at all...
> So no, in this case, I do not think we should change the wording.
> 
> The problem actually is rather the use of line numbers in a sed, which is
> really not explicit at all! But it was easier this way.
> 
> BTW, I agree about reordering the commands.

Reordering done at r11788

Pierre

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Inaccuracy in chroot page

[Pierre Labastie via lfs-dev]

Le 14/03/2020 à 17:36, Bruce Dubbs via lfs-dev a écrit :
> On 3/14/20 10:55 AM, Pierre Labastie via lfs-dev wrote:
>> Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit :
>>> On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote:
>>>> In "6.4 Entering the Chroot Environment", we have:
>>>> 
>>>>   From this point on, there is no need to use the LFS variable anymore,
>>>> because
>>>> all work will be restricted to the LFS file system. This is because the 
>>>> Bash
>>>> shell is told that $LFS is now the root (/) directory.
>>>> 
>>>> But it is not true that the bash shell is told anything: the _kernel_ is 
>>>> told
>>>> that $LFS is now the root (/) directory for all the processes launched by 
>>>> the
>>>> first one (that is, here, "env", which itself launches "bash", which will
>>>> launch all the others). I am not sure how to phrase this: something like:
>>>> -
>>>> ... system. This is because the kernel is told that $LFS is now the root 
>>>> (/)
>>>> directory for all the programs run from the current Bash shell.
>>>> -
>>>> But I'm sure native English writers can find something better (without
>>>> excluding non native of course :)
>>>
>>> I think I disagree with your premise.  bash IS told where the root directory
>>> is, but there is some interaction with the kernel.
>>>
>>> When I enter chroot, env no longer exists.  It does an 'exec' and replaces
>>> itself with bash. I took a look at /proc/ for that instance of bash and
>>> in that directory is the pseudo file 'mounts'. That tells me:
>>>
>>> /dev/sda6 / ext4 rw,noatime 0 0
>>>
>>> which is my /mnt/lfs directory on the host.  My interpretation is that this 
>>> is
>>> a configuration for bash.  When doing 'cd /', the kernel looks at this
>>> configuration for the bash instance and uses that to determine what disk
>>> partition (it could be a directory) to use for the head of an absolute path.
>>>
>>> In my opinion what we have now is correct.
>>>
>>
>>
>> Thinking a little more about this, what I mean is the following: bash is not
>> "told" anything, and does not "know" that "/" is $LFS: bash may ask the 
>> kernel
>> to open(2) (or stat(2), or other basic calls) a file by passing the filename
>> to the kernel, say, /a/file/name, and it is the kernel which resolves that
>> filename to $LFS/a/file/name, not bash itself.
> 
> I'm OK with:
> 
> This is because the Bash shell is set up so that $LFS is now the root (/)
> directory.
> 
> That is: sed /told/set up so/
> 

I just feel like I cannot explain. Bash is _unchanged_: it is the _kernel_,
which is set up so that $LFS is the new root for the process where bash (or
anything fork(2)ed from bash) is running. Anyway, nobody has complained for
years, let's not change anything. It does not prevent the build to work.

Pierre

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Inaccuracy in chroot page

[Pierre Labastie via lfs-dev]

Le 14/03/2020 à 16:00, Bruce Dubbs via lfs-dev a écrit :
> On 3/14/20 3:41 AM, Pierre Labastie via lfs-dev wrote:
>> In "6.4 Entering the Chroot Environment", we have:
>> 
>>  From this point on, there is no need to use the LFS variable anymore, 
>> because
>> all work will be restricted to the LFS file system. This is because the Bash
>> shell is told that $LFS is now the root (/) directory.
>> 
>> But it is not true that the bash shell is told anything: the _kernel_ is told
>> that $LFS is now the root (/) directory for all the processes launched by the
>> first one (that is, here, "env", which itself launches "bash", which will
>> launch all the others). I am not sure how to phrase this: something like:
>> -
>> ... system. This is because the kernel is told that $LFS is now the root (/)
>> directory for all the programs run from the current Bash shell.
>> -
>> But I'm sure native English writers can find something better (without
>> excluding non native of course :)
> 
> I think I disagree with your premise.  bash IS told where the root directory
> is, but there is some interaction with the kernel.
> 
> When I enter chroot, env no longer exists.  It does an 'exec' and replaces
> itself with bash. I took a look at /proc/ for that instance of bash and
> in that directory is the pseudo file 'mounts'. That tells me:
> 
> /dev/sda6 / ext4 rw,noatime 0 0
> 
> which is my /mnt/lfs directory on the host.  My interpretation is that this is
> a configuration for bash.  When doing 'cd /', the kernel looks at this
> configuration for the bash instance and uses that to determine what disk
> partition (it could be a directory) to use for the head of an absolute path.
> 
> In my opinion what we have now is correct.
> 


Thinking a little more about this, what I mean is the following: bash is not
"told" anything, and does not "know" that "/" is $LFS: bash may ask the kernel
to open(2) (or stat(2), or other basic calls) a file by passing the filename
to the kernel, say, /a/file/name, and it is the kernel which resolves that
filename to $LFS/a/file/name, not bash itself.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Ordering of Chapter 5 GGC Pass2 required external packages stanza

[Pierre Labastie via lfs-dev]

Le 14/03/2020 à 09:56, Kevin Buckley via lfs-dev a écrit :
> I note, because my PkgUser Book has explicit sections for
> unpacking the sources that the vanilla book doesn't, that,
> in Chapter 5 GGC Pass2, the order of actions prior to the
> creation of the build directory is:
> 
> 
> Unpack the required external packages
> Change the location of GCC's default dynamic linker
> On x86_64 hosts, set the default directory name for 64-bit libraries to “lib”:
> 
> 
> however in GCC Pass 2, it's
> 
> 
> Create a full version of an internal header
> Change the location of GCC's default dynamic linker
> On x86_64 hosts, set the default directory name for 64-bit libraries to “lib”:
> Unpack the required external packages
> Fix a problem introduced by Glibc-2.31
> 
> 
> Is there any reason why the required external packages can't be
> the first thing done in GCC Pass 2 as well?
> 
> Indeed, is there any reason why the ordering in GCC Pass 2
> couldn't be:
> 
> 
> Unpack the required external packages
> Change the location of GCC's default dynamic linker
> On x86_64 hosts, set the default directory name for 64-bit libraries to “lib”:
> Create a full version of an internal header
> Fix a problem introduced by Glibc-2.31
> 
> where the two actions not carried out in Pass 1 come
> after the three that are?
> 
> Given that there is no reason given for the change in order,
> I think this would make the two Pass sections more similar,
> thereby highlighting the differences in the second pass.
> 
> 
> I could also suggest that the wording
> 
> Now fix a problem introduced by Glibc-2.31:
> 
> might be more explict about why, so perhaps:
> 
> Now fix a problem introduced by the Glibc-2.31 we have just built:
> 

I think this will be removed in next version of gcc (as mentioned by Xi
Ruoyao), but in case this isn't, and glibc-2.32 appears, the problem will
still have been introduced by glibc-2.31, which we won't be building at all...
So no, in this case, I do not think we should change the wording.

The problem actually is rather the use of line numbers in a sed, which is
really not explicit at all! But it was easier this way.

BTW, I agree about reordering the commands.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Inaccuracy in chroot page

[Pierre Labastie via lfs-dev]

In "6.4 Entering the Chroot Environment", we have:

From this point on, there is no need to use the LFS variable anymore, because
all work will be restricted to the LFS file system. This is because the Bash
shell is told that $LFS is now the root (/) directory.

But it is not true that the bash shell is told anything: the _kernel_ is told
that $LFS is now the root (/) directory for all the processes launched by the
first one (that is, here, "env", which itself launches "bash", which will
launch all the others). I am not sure how to phrase this: something like:
-
... system. This is because the kernel is told that $LFS is now the root (/)
directory for all the programs run from the current Bash shell.
-
But I'm sure native English writers can find something better (without
excluding non native of course :)

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Complete removal of docbook snapshot

[Pierre Labastie via lfs-dev]

Hi all,
I've removed completely the docbook snapshot at r11779 and r11780. Testing on
my system with installed docbook-xsl-1.79.1 (or 2) generated the same book (up
to meta information) as with the previous system.

I hope everybody has a usable docbook stylesheet installation. And that higgs
has it too (normally yes, since it can render blfs).

Please let me know if you see anything wrong or weird with this. I apologize
in advance for any inconvenience.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Building Glibc without the Info pages?

[Pierre Labastie via lfs-dev]

Le 12/03/2020 à 03:52, Kevin Buckley via lfs-dev a écrit :
> On Tue, 10 Mar 2020 at 17:59, Pierre Labastie via lfs-dev
>  wrote:
>> ...
>> what if you tried passing "MAKEINFO=/bin/true" to configure?
>>
>> Pierre
> 
> Gets you very close.
> 
> make MAKEINFO=/bin/true install
> 
> then fails at the point where it tries to access
> 
> manual/glibc.info*
> 
> as the target for a copy or move, because no Info files have been generated.
> 
> If, as I did, you then think to simply
> 
> touch manual/glibc.info
> 
> so as to have something to access at that point, you then fail when the
> 
> install-info
> 
> target runs, because the manual/glibc.info file is empty and install-info
> doesn't like that.
> 
> You can avoid that by echoing something into
> 
> manual/glibc.info
> 
> ahead of the make MAKEINFO=/bin/true install
> 
> For example, something akin to the firstline of most info files
> 
> $ echo "This is glibc.info, produced by makeinfo version from
> glibc.texi" > manual/glibc.info
> $ make MAKEINFO=/bin/true install ...
> 
> That seemed to do the trick - thanks for the pointer to the start of the path.
> Kevin
> 

Sorry, looks like there is something "magic" in glibc source, and that it is
better to use "MAKEINFO=:". See manual/Makefile in glibc source tree:
-
ifneq ($(strip $(MAKEINFO)),:)
info: $(objpfx)libc.info
endif
[...]
ifneq ($(PERL),no)
ifneq ($(strip $(MAKEINFO)),:)
install: $(inst_infodir)/libc.info
@if $(SHELL) -c '$(INSTALL_INFO) --version' >/dev/null 2>&1; then \
 test -f $(inst_infodir)/dir || $(INSTALL_DATA) dir $(inst_infodir);\
 $(INSTALL_INFO) --info-dir=$(inst_infodir) #wrapped by mailer
$(inst_infodir)/libc.info;\
else : ; fi
endif
endif
-

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Building Glibc without the Info pages?

[Pierre Labastie via lfs-dev]

Le 10/03/2020 à 10:19, Kevin Buckley via lfs-dev a écrit :
> As I usually build against Thomas Trepl's Multilib book, I've realised
> that I end up building the Glibc Info pages SIX times, three in Chapter 5
> and three in Chapter 6.
> 
> I've been looking at the Glibc Makefile hierarchy but couldn't see an
> obvious place at which to prevent the Info pages being built.
> 
> It looks like there's a subdir build on the "manual" subdirectory
> during the "make install" but I'm having a hard time unravelling
> the actual target and/or rule to avoid.
> 
> Anyone on here got any "previous" in this area?
> Kevin
> 
what if you tried passing "MAKEINFO=/bin/true" to configure?

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Should we keep the "milestone" entity in general.ent

[Pierre Labastie via lfs-dev]

Le 02/03/2020 à 16:06, Bruce Dubbs via lfs-dev a écrit :
> On 3/2/20 3:11 AM, Pierre Labastie via lfs-dev wrote:
>> Presently, this entity is 9.0, and has been last changed in July 2019. The
>> questions are:
>> - what's its use?
>> - if it is used, shouldn't it be changed to 9.2?
>> - it not, shouldn't it be removed?
> 
> I just forgot to make it completed.  Now done for both LFS and BLFS.
> 
>   -- Bruce

I was talking about the "milestone" _entity_ in general.ent in LFS svn book...
I do not see that you have changed anything.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Should we keep the "milestone" entity in general.ent

[Pierre Labastie via lfs-dev]

Presently, this entity is 9.0, and has been last changed in July 2019. The
questions are:
- what's its use?
- if it is used, shouldn't it be changed to 9.2?
- it not, shouldn't it be removed?

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 16:31, Pierre Labastie via lfs-dev a écrit :
> Le 23/02/2020 à 15:49, Tadeus Prastowo via lfs-dev a écrit :
>>
>> I am glad to help.  But, really, test what you fly, and fly what you
>> test.  In other words, don't do an SVN build to write the book's text
>> (note that GCC has just moved from SVN to git this new year).  Thank
>> you.
> 
> I only did that once to anticipate the upcoming need for C++ when building
> gcc. Actually, everybody thought that we would have to move to a three-pass
> build, and the libstdc++ trick allowed to keep only two passes. But I can tell
> you that it took a lot of "blood, toil, tears and sweat" before coming up with
> the current solution! Eventually, it was ready when 4.8 came out, which would
> not have been possible without working with svn...
> 

This switch finally removed at r11770...

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] The nochuncks book doesn't get the aux-file-data.sh changes

[Pierre Labastie via lfs-dev]

Le 01/03/2020 à 07:55, Kevin Buckley via lfs-dev a écrit :
> On Sun, 1 Mar 2020 at 01:16, Pierre Labastie via lfs-dev
>  wrote:
>>
>> Le 29/02/2020 à 16:09, Bruce Dubbs via lfs-dev a écrit :
>>> On 2/29/20 4:57 AM, Pierre Labastie via lfs-dev wrote:
>>>
>>>>>
>>>>> Assuming there's no reason why the noChunks book shouldn't
>>>>> be created from the xmllint-ed source, (1) looks the cleaner
>>>>> solution.
>>>>>
>>>>
>>>> Since the prereqs for nochunks are validate and profile-html, I think
>>>> lfs-html.xml, which is generated by those prereqs, should be used...
>>>>
>>>> Can you just try to change html2 to html in the nochuncks code?
>>>>
>>>> It it works for you, I'll make the change in svn
>>>
>>> Since we will be releasing 0.1 tomorrow, please do not make any changes to 
>>> the
>>> Makefile.  The release scripts depend on it.
>>>
>>
>> Ok
>> Pierre
> 
> Just to say that I should have mentioned that I had already
> tried that change and it had worked.
> 

Ok, Thanks. Waiting for Bruce's "green light" because I am not sure what the
impact on release scripts will be. Note that the generated:
http://www.linuxfromscratch.org/lfs/downloads/9.1/LFS-BOOK-9.1-NOCHUNKS.html
is correct.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] The nochuncks book doesn't get the aux-file-data.sh changes

[Pierre Labastie via lfs-dev]

Le 29/02/2020 à 16:09, Bruce Dubbs via lfs-dev a écrit :
> On 2/29/20 4:57 AM, Pierre Labastie via lfs-dev wrote:
> 
>>>
>>> Assuming there's no reason why the noChunks book shouldn't
>>> be created from the xmllint-ed source, (1) looks the cleaner
>>> solution.
>>>
>>
>> Since the prereqs for nochunks are validate and profile-html, I think
>> lfs-html.xml, which is generated by those prereqs, should be used...
>>
>> Can you just try to change html2 to html in the nochuncks code?
>>
>> It it works for you, I'll make the change in svn
> 
> Since we will be releasing 0.1 tomorrow, please do not make any changes to the
> Makefile.  The release scripts depend on it.
> 

Ok
Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] The nochuncks book doesn't get the aux-file-data.sh changes

[Pierre Labastie via lfs-dev]

Le 29/02/2020 à 11:39, Kevin Buckley via lfs-dev a écrit :
> I do hope I have this right: I don't think this one is down
> to my rendering environment.
> 
> As I think of it, there are three files created in RENDERTMP
> 
>   lfs-html2.xml
>   lfs-full.xml
>   lfs-html.xml
> 
> resulting from this pipeline (simplfied) in the Makefile
> 
>   xsltproc  index.xml --output lfs-html2.xml
> 
>   xmllint   lfs-html2.xml  -o  lfs-full.xml
> 
>   xsltproc  lfs-full.xml   --output lfs-html.xml
> 
> and then the Chunked book gets created by an
> 
>   xsltproc  lfs-html.xml
> 
> 
> The noChunks book, however, gets created by an
> 
>   xsltproc  lfs-html2.xml   --output LFS-BOOK.html
> 
> 
> Note that the "source" of the noChunks book is not the
> same as that of the Chunked book.
> 
> Note also that validate target in the Makefile does a
> 
>./aux-file-data.sh $(RENDERTMP)/lfs-full.xml
> 
> 
> and that that aux-file-data.sh does some substituion
> inside its file argument, as follows
> 
> 
> sed -i -e s/BOOTSCRIPTS-SIZE/$bootsize/  \
>-e s/BOOTSCRIPTS-INSTALL-KB/$bootinstallsize/ \
>-e s/BOOTSCRIPTS-MD5SUM/$bootmd5/ $FILE
> 
> 
> What this seems to mean is that the noChunks book doesn't
> "see" any changes made by aux-file-data.sh and so ends up
> rendering, for example, in Chapter 3's package listing
> 
>   LFS-Bootscripts (20191031) - BOOTSCRIPTS-SIZE KB:
> 
> rather than
> 
>   LFS-Bootscripts (20191031) - 32 KB:
> 
> 
> It also means that the noChunkc book isn't being created
> from the xmllint-ed source either.
> 
> 
> As I'm not sure why the noChunks book gets rendered from the
> very first source in the temporary chain, it's not clear which
> is the correct way to address this.
> 
> 
> FWIW, the ways I've thought of so far are:
> 
> 1) Render the noChunks book from the second or third sources,
> so lfs-full.xml or lfs-html.xml, in the temporary chain.
> 
> 2) Run the aux-file-data.sh against the first source
> in the temporary chain, lfs-html2.xml, as well as,
> or before, running it on lfs-full.xml
> 
> Assuming there's no reason why the noChunks book shouldn't
> be created from the xmllint-ed source, (1) looks the cleaner
> solution.
> 

Since the prereqs for nochunks are validate and profile-html, I think
lfs-html.xml, which is generated by those prereqs, should be used...

Can you just try to change html2 to html in the nochuncks code?

It it works for you, I'll make the change in svn

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 15:49, Tadeus Prastowo via lfs-dev a écrit :
> 
> I am glad to help.  But, really, test what you fly, and fly what you
> test.  In other words, don't do an SVN build to write the book's text
> (note that GCC has just moved from SVN to git this new year).  Thank
> you.

I only did that once to anticipate the upcoming need for C++ when building
gcc. Actually, everybody thought that we would have to move to a three-pass
build, and the libstdc++ trick allowed to keep only two passes. But I can tell
you that it took a lot of "blood, toil, tears and sweat" before coming up with
the current solution! Eventually, it was ready when 4.8 came out, which would
not have been possible without working with svn...

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 15:06, Tadeus Prastowo a écrit :
> On Sun, Feb 23, 2020 at 9:48 AM Pierre Labastie via lfs-dev
>  wrote:
>>
>> Le 23/02/2020 à 09:20, Tadeus Prastowo via lfs-dev a écrit :
>>> In other words, the description of the option given in the LFS book
>>> about some C library or libgcc not being compiled with a thread
>>> support is just wrong.
>>>
>>
>> Because upstream have added an option for a reason does not mean that it is
>> the only reason for using it. Upstream does not support the way we do thing 
>> in
>> LFS, so they may have never had the same problem as I have had. But I can
>> swear that at some point, the build could not be done without this option.
>> Also on svn versions before 4.8, I had to construct the directory layout of a
>> complete build of gcc when building libstdc++ (that is something like 
>> creating
>> build//libstdc++ and working from there). That requirement was 
>> removed
>> at some point before releasing 4.8. Note that svn gcc changes several times a
>> day, and sometimes may break completely, so my tests were done without
>> following the updates.
> 
> Thank you for pointing that out.  Now it makes sense.
> 
>> But I agree with you this is old history, and that the option should be
>> removed. Not just now though: have you tested on several machines and 
>> distros?
>> (me neither yet).
> 
> No.  I have only one machine with one distro that I have been wanting
> to ditch.  In this surveillance age, liberty indeed means hard work,

like writing "free" in hex ;)

> including building and maintaining one's own operating system.  That's
> why I cannot just gulp what the LFS book says.

And that helps us. We are a very small team for maintaining both LFS and BLFS,
that is around 900 packages. If each one had one release per year, that would
mean three updates to test per day. And most of them have many more than just
one release per year... So sure enough some options may become useless without
us noticing it, if they do not break something!

Be assured that I appreciated your inputs: although it is not very enjoyable
to be proven wrong, I had to be (but not without arguing :).

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--with-sysroot' description?

[Pierre Labastie via lfs-dev]

Le 22/02/2020 à 23:04, Pierre Labastie via lfs-dev a écrit :
> Le 21/02/2020 à 21:50, Pierre Labastie via lfs-dev a écrit :
>> Le 21/02/2020 à 18:15, Tadeus Prastowo a écrit :
>>> Some corrections below, keeping in mind that the binutils build is a
>>> native build, not a cross build.
>>>
>>> On Fri, Feb 21, 2020 at 6:05 PM Tadeus Prastowo <0x66726...@gmail.com> 
>>> wrote:
>>>>
>>>> Hi Pierre,
>>>>
>>>> On Fri, Feb 21, 2020 at 11:01 AM Pierre Labastie via lfs-dev
>>>>  wrote:
>>>>>
>>>>> Le 21/02/2020 à 05:33, Bruce Dubbs via lfs-dev a écrit :
>>>>>> On 2/20/20 10:09 PM, Xi Ruoyao via lfs-dev wrote:
>>>>>>> No.  The linker (/usr/bin/ld) looks at ld.so.conf, but the dynamic 
>>>>>>> linker
>>>>>>> (/lib/ld-linux-x86-64.so.2) looks at ld.so.cache.
>>>>>>
>>>>>> You're right.  I got the tools mixed up.  Thanks.
>>>>>>
>>>>>>   -- Bruce
>>>>>>
>>>>>>>> I'll use the above to try to reword the explanation of the
>>>>>>>> --with-sysroot option.
>>>>>
>>>>> Actually, the main use of the --with-sysroot switch is that it changes the
>>>>> behavior of ld with respect to the -rpath switch. From man ld:
>>>>>
>>>>>The linker uses the following search paths to locate required
>>>>>shared libraries:
>>>>>
>>>>>1.  Any directories specified by -rpath-link options.
>>>>>
>>>>>2.  Any directories specified by -rpath options.  The 
>>>>> difference
>>>>>between -rpath and -rpath-link is that directories 
>>>>> specified by
>>>>>-rpath options are included in the executable and used at
>>>>>runtime, whereas the -rpath-link option is only effective 
>>>>> at
>>>>>link time. Searching -rpath in this way is only supported 
>>>>> by
>>>>>native linkers and cross linkers which have been configured
>>>>>with the --with-sysroot option.
>>>>>
>>>>> So I think "-rpath" should appear somewhere in this explanation.
>>>>
>>>> But, pay attention to the following passage: "Searching -rpath in this
>>>> way [(i.e., any directories specified by -rpath options)] is only
>>>> supported by [...] cross linkers which have been configured with the
>>>> --with-sysroot option."  It means that, if the `--with-sysroot' option
>>>> is not given to configure binutils, the resulting ld will ignore any
>>>> -rpath given in the command line.  This means that not specifying the
>>>> `--with-sysroot' option is indeed a good idea because any path
>>>> specified using the `-rpath' option will simply be ignored, keeping
>>>> the /tools isolated from the build system.
>>
>> That's exactly the converse: it's gcc which sets -rpath to the directories
>> that should be searched, and gcc knows that it should look for dependent
>> libraries in /tools.
>>
>>>
>>> No, the `-rpath' option is not ignored because the problem at hand is
>>> building a native binutils.
>>>
>>>>> The --with-sysroot switch has not effect if ld is called without -rpath 
>>>>> option...
>>>>
>>>> That's not true for the problem at hand because the `--with-sysroot'
>>>> switch indeed has an effect as already reported in the other thread
>>>> despite the absent of the `-rpath' option in the linking command.
>>>
>>> This stands correct.  The `--with-sysroot' option has an effect even
>>> if ld is called without any `-rpath' option.
>>>
>>>> And, the problem at hand uses an ld for a static linking to obtain the
>>>> perl executable because both the option `-shared' and *.so files are
>>>> not specified in the linking command, no?
>>
>> I'm not sure. First, the errors occur in a linking command using "cc" (that 
>> is
>> gcc), so -rpath is set behind the hood. Second, even when not specifying
>> -shared, dependent libraries may be shared... And actually, the problem 
>> occurs
>> in libpthread.so.0.
>>
> 
> Err, well, I'm wrong. I think this used to be the case that -rpath was set by
> gcc, but not anymore... And your explanation is (almost) right: if
> --with-sysroot is set to a non-existent directory, /etc/ld.so.conf is searched
> into this directory and not found. Then ld falls back to the SEARCH_DIR path
> of the ld script (I think).
> When the --with-sysroot switch was added (in 2013 or so), it was to fix a
> problem with building "check" in chapter 5 (we do not do that anymore), and
> that one was using -rpath.
> It's late here now (I've been studying the ld code almost all day), I'll try
> to rewrite the explanation tomorrow.
> 
> Pierre
> 

Done at r11758. I've also filed a bug upstream [1], because IMHO, the
documentation is misleading.

Pierre
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25588
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 09:20, Tadeus Prastowo via lfs-dev a écrit :
> On Sun, Feb 23, 2020 at 7:58 AM Pierre Labastie via lfs-dev
>  wrote:
>>
>> Le 23/02/2020 à 07:21, Pierre Labastie via lfs-dev a écrit :
>>> Le 23/02/2020 à 00:33, Tadeus Prastowo via lfs-dev a écrit :
>>>> On Sat, Feb 22, 2020 at 11:10 PM Pierre Labastie via lfs-dev
>>>>  wrote:
>>>>>
>>>>> Le 22/02/2020 à 18:33, Tadeus Prastowo via lfs-dev a écrit :
>>>>>> On Sat, Feb 22, 2020 at 6:17 PM Douglas R. Reno via lfs-dev
>>>>>>  wrote:
>>>>>>> If we're going off an 'svn blame', it was done at r10226. That would've
>>>>>>> been GCC-4.8.0:
>>>>>>>
>>>>>>> http://wiki.linuxfromscratch.org/lfs/browser/trunk/BOOK/chapter05/libstdc%2B%2B.xml?annotate=blame
>>>>>>
>>>>>> Thank you very much for the pointer.  I see that the change was
>>>>>> committed by Pierre.
>>>>>
>>>>> I'm almost sure the option was needed at the time. gcc-4.8.0 was the 
>>>>> first gcc
>>>>> to be written in C++, hence the need for adding C++ support in pass1.
>>>>
>>>> I think the `--disable-libstdcxx-threads' option was not needed even
>>>> at that time.  In other words, I am sure that the option was included
>>>> in the book without a failing build to support the use of the option
>>>> (perhaps the option was included just because its name includes the
>>>> word `threads').
>>>
>>> I'm sure I included that because the build was failing. But I remember I've
>>> been working with svn versions of gcc before 4.8 was released. So it is
>>> possible I have not tested that it was still needed for 4.8.
> 
> Even with the SVN version, I think the build failed not because of
> lacking the option.  I have checked the GCC changelog for the option,
> and the sole reason the option was added is to avoid a __potential__
> program crash when Solaris executables compiled in a newer Solaris are
> run in an older Solaris (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52189 for the details).
> The potential program crash, however, virtually cannot happen when
> following the LFS book because who would stop after compiling the
> libstdc++ just to use an older Solaris version to obtain the second
> pass GCC?
> 
> In other words, the description of the option given in the LFS book
> about some C library or libgcc not being compiled with a thread
> support is just wrong.
> 

Because upstream have added an option for a reason does not mean that it is
the only reason for using it. Upstream does not support the way we do thing in
LFS, so they may have never had the same problem as I have had. But I can
swear that at some point, the build could not be done without this option.
Also on svn versions before 4.8, I had to construct the directory layout of a
complete build of gcc when building libstdc++ (that is something like creating
build//libstdc++ and working from there). That requirement was removed
at some point before releasing 4.8. Note that svn gcc changes several times a
day, and sometimes may break completely, so my tests were done without
following the updates.

But I agree with you this is old history, and that the option should be
removed. Not just now though: have you tested on several machines and distros?
(me neither yet).

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 07:21, Pierre Labastie via lfs-dev a écrit :
> Le 23/02/2020 à 00:33, Tadeus Prastowo via lfs-dev a écrit :
>> On Sat, Feb 22, 2020 at 11:10 PM Pierre Labastie via lfs-dev
>>  wrote:
>>>
>>> Le 22/02/2020 à 18:33, Tadeus Prastowo via lfs-dev a écrit :
>>>> On Sat, Feb 22, 2020 at 6:17 PM Douglas R. Reno via lfs-dev
>>>>  wrote:
>>>>> If we're going off an 'svn blame', it was done at r10226. That would've
>>>>> been GCC-4.8.0:
>>>>>
>>>>> http://wiki.linuxfromscratch.org/lfs/browser/trunk/BOOK/chapter05/libstdc%2B%2B.xml?annotate=blame
>>>>
>>>> Thank you very much for the pointer.  I see that the change was
>>>> committed by Pierre.
>>>
>>> I'm almost sure the option was needed at the time. gcc-4.8.0 was the first 
>>> gcc
>>> to be written in C++, hence the need for adding C++ support in pass1.
>>
>> I think the `--disable-libstdcxx-threads' option was not needed even
>> at that time.  In other words, I am sure that the option was included
>> in the book without a failing build to support the use of the option
>> (perhaps the option was included just because its name includes the
>> word `threads').
> 
> I'm sure I included that because the build was failing. But I remember I've
> been working with svn versions of gcc before 4.8 was released. So it is
> possible I have not tested that it was still needed for 4.8.
> 
> In any case, there is now code in libstdc++ configure script to test whether
> threads are available, and it automatically disables threads if they are not
> available.
> 
> I think we could completely remove the option: this libstdc++ is only used for
> building gcc-pass2, so possibly changing it has no relevance to other parts of
> the book, if gcc-pass2 builds successfully. BUt Since lfs is frozen, I'll only
> change the text.
> 
> Pierre
> 

Reworded this and also the one about --with-sysroot in binutils-pass2 at rev
11758. Thanks for the discussion.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 23/02/2020 à 00:33, Tadeus Prastowo via lfs-dev a écrit :
> On Sat, Feb 22, 2020 at 11:10 PM Pierre Labastie via lfs-dev
>  wrote:
>>
>> Le 22/02/2020 à 18:33, Tadeus Prastowo via lfs-dev a écrit :
>>> On Sat, Feb 22, 2020 at 6:17 PM Douglas R. Reno via lfs-dev
>>>  wrote:
>>>> If we're going off an 'svn blame', it was done at r10226. That would've
>>>> been GCC-4.8.0:
>>>>
>>>> http://wiki.linuxfromscratch.org/lfs/browser/trunk/BOOK/chapter05/libstdc%2B%2B.xml?annotate=blame
>>>
>>> Thank you very much for the pointer.  I see that the change was
>>> committed by Pierre.
>>
>> I'm almost sure the option was needed at the time. gcc-4.8.0 was the first 
>> gcc
>> to be written in C++, hence the need for adding C++ support in pass1.
> 
> I think the `--disable-libstdcxx-threads' option was not needed even
> at that time.  In other words, I am sure that the option was included
> in the book without a failing build to support the use of the option
> (perhaps the option was included just because its name includes the
> word `threads').

I'm sure I included that because the build was failing. But I remember I've
been working with svn versions of gcc before 4.8 was released. So it is
possible I have not tested that it was still needed for 4.8.

In any case, there is now code in libstdc++ configure script to test whether
threads are available, and it automatically disables threads if they are not
available.

I think we could completely remove the option: this libstdc++ is only used for
building gcc-pass2, so possibly changing it has no relevance to other parts of
the book, if gcc-pass2 builds successfully. BUt Since lfs is frozen, I'll only
change the text.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] A misleading `--disable-libstdcxx-threads' description?

[Pierre Labastie via lfs-dev]

Le 22/02/2020 à 18:33, Tadeus Prastowo via lfs-dev a écrit :
> On Sat, Feb 22, 2020 at 6:17 PM Douglas R. Reno via lfs-dev
>  wrote:
>>
>>
>> On 2/22/20 11:14 AM, Tadeus Prastowo via lfs-dev wrote:
>>> On Fri, Feb 21, 2020 at 9:54 PM Pierre Labastie via lfs-dev
>>>  wrote:
>>>> Actually, glibc has all the bells and whistles it would have in a native
>>>> build. The problem at this stage is libgcc.a, which comes with gcc, not 
>>>> with
>>>> glibc... And this one has no support for threads.
>>> For sure, libgcc.a (not glibc) is a better explanation.
>>>
>>>> OTOH, I've not tried without this option for a while, maybe now it is not
>>>> needed anymore.
>>> No, it is not needed anymore.  But, were it needed before?  Any
>>> recollection to which GCC version needed it?  Thanks.
>>
>> If we're going off an 'svn blame', it was done at r10226. That would've
>> been GCC-4.8.0:
>>
>> http://wiki.linuxfromscratch.org/lfs/browser/trunk/BOOK/chapter05/libstdc%2B%2B.xml?annotate=blame
> 
> Thank you very much for the pointer.  I see that the change was
> committed by Pierre.

I'm almost sure the option was needed at the time. gcc-4.8.0 was the first gcc
to be written in C++, hence the need for adding C++ support in pass1.

> So, by writing "Since we have not yet built the
> C threads library", Pierre really means "Since we have not yet built
> the [libgcc library with] threads [support]".  So, I think the
> description really has to be updated so as not to be misleading.
> Thanks.
> 

Agreed
Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page