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

[Firas Khalil Khana via lfs-dev]

On Tue, May 19, 2020 at 10:33 PM Akira Urushibata via lfs-dev
 wrote:
>
> Is there any problem with making a new directory at the filesystem
> base level?
>
> In theory there could be a distribution which already has a /tool
> directory.  But I have never heard of that.
>
> What alternatives are there to /tool ?  If /tool is so abhored, why
> not try /usr/local instead ?  What happens when you do that?
> The /usr/local directory must be empty for this to work and you
> shouldn't do anything other than build LFS on this system.  But if
> you dislike /tool , it should be worth a try.
>
>
>
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

No not at all, I'm actually a fan of the `/tools` symlink on the host
file system (as it has become sort of a convention, and it's known by
many users), but I was just seeing if providing it can be optional.

I understand that `/$dir` and `/home/lfs/$dir` have to exist to get
the chroot linker's paths correctly sorted out, but after looking at
some other options, I'm lead into thinking that `/tools` might be the
best place for this symlink to go to. Some alternatives are:

1- No host symlink, will have to be `/home/lfs/home/lfs/tools` symlink
to `/home/lfs/tools` in order to work inside and outside of chroot.
Pros: No host symlink
Cons: Inconvenient path `/home/lfs/home/lfs/tools

2- `/opt/lfs/tools` host symlink to `/home/lfs/opt/lfs/tools` (will
also have to provide /home/lfs/tools -> `/home/lfs/opt/lfs/toolchain`
or vice versa because it's what the user expects).
Pros: Host symlink conforms to FHS v3.0
Cons: Still a host symlink + inconvenient name
`/home/lfs/opt/lfs/tools` (might also be overridden when an opt dir is
actually needed inside chroot?) + an additional symlink
/home/lfs/tools for where the user expects to find the toolchain.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

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

[Firas Khalil Khana via lfs-dev]

On Sat, May 16, 2020 at 6:46 AM Xi Ruoyao via lfs-dev
 wrote:
>
> On 2020-05-16 06:03 +0300, Firas Khalil Khana via lfs-dev wrote:
> > On Sat, May 16, 2020 at 5:48 AM Xi Ruoyao via lfs-dev
> >  wrote:
> > > On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote:
> > > > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev
> > > >  wrote:
> > > > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote:
> > > > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev
> > > > > >  wrote:
> > > > > > > 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?
> > > > >
> > > > > No,  unless we use some DESTDIR installation.  It's Pierre's cross
> > > > > Chapter 5
> > > > > experiment:
> > > > >
> > > > > http://www.linuxfromscratch.org/~pierre/lfs-modified/
> > > > >
> > > >
> > > > I've checked piere's modifications, and they're most welcome, but I'm
> > > > only talking about removing the `/tools` symlink without touching
> > > > anything else.
> > > >
> > > > I don't think GCC needs its source modifications be changed (meaning
> > > > that we'll still use the regular `/tools/lib`), and I think that's
> > > > made possible because sysroot is actually appended before ld's search
> > > > path (one thing that might require minor modification is that when ld
> > > > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying
> > > > `t-linux64` to use `../lib` instead of `../lib64`) path relative to
> > > > where it is, it won't get the right `lib` folder as it gets to
> > > > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the
> > > > configuration passed to the toolchain components.
> > >
> > > It's not about library search path.  It's about GCC internal executable
> > > path.
> > > When you configure GCC with --prefix=/mnt/lfs/tools, the path
> > > "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded 
> > > into
> > > executables gcc, g++, etc.  When this GCC build is used, it searches
> > > internal
> > > executables cc1, cc1plus, etc. in this path.  So if we use --
> > > prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot
> > > (gcc
> >

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

[Firas Khalil Khana via lfs-dev]

On Sat, May 16, 2020 at 5:48 AM Xi Ruoyao via lfs-dev
 wrote:
>
> On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote:
> > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev
> >  wrote:
> > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote:
> > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev
> > > >  wrote:
> > > > > 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?
> > >
> > > No,  unless we use some DESTDIR installation.  It's Pierre's cross 
> > > Chapter 5
> > > experiment:
> > >
> > > http://www.linuxfromscratch.org/~pierre/lfs-modified/
> > >
> >
> > I've checked piere's modifications, and they're most welcome, but I'm
> > only talking about removing the `/tools` symlink without touching
> > anything else.
> >
> > I don't think GCC needs its source modifications be changed (meaning
> > that we'll still use the regular `/tools/lib`), and I think that's
> > made possible because sysroot is actually appended before ld's search
> > path (one thing that might require minor modification is that when ld
> > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying
> > `t-linux64` to use `../lib` instead of `../lib64`) path relative to
> > where it is, it won't get the right `lib` folder as it gets to
> > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the
> > configuration passed to the toolchain components.
>
> It's not about library search path.  It's about GCC internal executable path.
> When you configure GCC with --prefix=/mnt/lfs/tools, the path
> "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded into
> executables gcc, g++, etc.  When this GCC build is used, it searches internal
> executables cc1, cc1plus, etc. in this path.  So if we use --
> prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot 
> (gcc
> will say something like 'cc1 not found').  And there is a GCC library path
> "/mnt/lfs/tools/lib/gcc/x86_64-linux-gnu/10.1.0" contains libgcc libraries and
> headers.  It's also hardcoded.
>

^ This needs to be added to the book, along with explanations for the
rest of the stuff LFS does to get a cross/native toolchain to work.
Also if that's the case, why not rely on empty prefixes, and resolve
to `DESTDIR`s instead?

> One way to solve this is to add CC="gcc -B /tools/libexec/gcc/x86_64-linux-
> gnu/10.1.0 -L /tools/lib/gcc/x86_64-linux-gnu/10.1.0 -I /tools/lib/gcc/x86_64-
> linux-gnu/10.1.0/include" in early Chapter 6 packages.  I believe such a long
> $CC is stupid.
>
> Another way, already said by Pierre, is "ln -sv /tools /mnt/lfs" in chroot
> environment.
>
> > > > > > 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 
> >

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

[Firas Khalil Khana via lfs-dev]

On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev
 wrote:
>
> On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote:
> > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev
> >  wrote:
> > > 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?
>
> No,  unless we use some DESTDIR installation.  It's Pierre's cross Chapter 5
> experiment:
>
> http://www.linuxfromscratch.org/~pierre/lfs-modified/
>

I've checked piere's modifications, and they're most welcome, but I'm
only talking about removing the `/tools` symlink without touching
anything else.

I don't think GCC needs its source modifications be changed (meaning
that we'll still use the regular `/tools/lib`), and I think that's
made possible because sysroot is actually appended before ld's search
path (one thing that might require minor modification is that when ld
inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying
`t-linux64` to use `../lib` instead of `../lib64`) path relative to
where it is, it won't get the right `lib` folder as it gets to
`/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the
configuration passed to the toolchain components.

> > > > 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
> >
> > I understand that due to chroot environment $LFS/tools will eventually
> > become /tools and the path to the link inside every binary produced in
> > Chapter 5 (due to the modification of the GCC sources) will thus
> > remain valid inside chroot, but wouldn't it be better to spare the
> > host system?
>
> Now we know it works well.  And we know there is no other packages using 
> /tools
> (we've discussed this in lfs-dev long times ago).  /tools is a simple symlink 
> in
> host so it's easy to remove.
>

I don't think it's as simple as you've mentioned, many users have
reported problems when doing the exact same steps in LFS but without
creating the `/tools` symlink, here's one I found recently:

https://stackoverflow.com/questions/59705962/ld-fails-to-find-libc-when-compiling-first-pass-of-cross-gcc

If it were simple, can you please provide instructions on how to "not
create" this symlink for users who don't want to pollute their host
system?

> > Also I apologize for the error in the name of this message as it's
> > supposed to be /tools and not /toolchain.
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

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

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

[Firas Khalil Khana via lfs-dev]

On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev
 wrote:
>
> 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

I understand that due to chroot environment $LFS/tools will eventually
become /tools and the path to the link inside every binary produced in
Chapter 5 (due to the modification of the GCC sources) will thus
remain valid inside chroot, but wouldn't it be better to spare the
host system?

Also I apologize for the error in the name of this message as it's
supposed to be /tools and not /toolchain.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

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

[Firas Khalil Khana via lfs-dev]

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

[Firas Khalil Khana via lfs-dev]

On Thu, May 14, 2020 at 10:39 AM Pierre Labastie via lfs-dev
 wrote:
>
> 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

It's true that starting from GCC 10, it now defaults to `-fno-common`:
https://gcc.gnu.org/gcc-10/porting_to.html

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`.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] chapter6: move Zstd before GCC?

[Firas Khalil Khana via lfs-dev]

On Sun, May 10, 2020 at 5:18 AM Xi Ruoyao via lfs-dev
 wrote:
>
> Now GCC optionally depends on zstd (using it like zlib to compress LTO IR).
> Should we move zstd before GCC?
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

Well it's optional, and by building it before GCC then passing
`--with-zstd` to GCC, LTO will default to zstd and fallback to zlib.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

On Sat, May 9, 2020 at 4:57 AM Xi Ruoyao via lfs-dev
 wrote:
>
> On 2020-05-06 14:16 +0300, Firas Khalil Khana via lfs-dev wrote:
> > On Wed, May 6, 2020 at 1:56 PM Xi Ruoyao via lfs-dev wrote:
> > > Pierre recently discovered the circular dependency between eudev (in
> > > Sysvinit
> > > book) and util-linux:
> > >
> > > > util-linux uses libudev (eudev) in lsblk (with fallback to libblkid from
> > > > util-
> > > > linux if libudev has not been linked). And udev uses libblkid to find
> > > > information about some block devices (specialy cdrom_id, ata_id, etc).
> > > > Note
> > > > that this is well known and cured in systemd book.
> >
> > Oh I forgot that this is related to how Util-linux and e2fsprogs are
> > configured. So Chapter 5 Util-linux will have to rely on the host's
> > libudev, while Chapter 6 Util-linux will have to rely on the eudev we
> > provide.
>
> Chap. 5 Util-linux does not use libudev.  Since it's temporal we don't need 
> the
> additional functionality added by linking to libudev in Chapter 5.
>
> For your approach, I found some issues preparing it:
>
> > 1- Ncurses can be removed? or is it needed for Chapter 5 Python which in 
> > turn
> > is needed for Chapter 6 Glibc? Perhaps it can be removed for those using
> > different C libraries (e.g. musl)?
> >
> > 2- Bash (The chroot environment's shell) can be built without curses support
> > by passing "--without-curses", until it gets rebuilt again in Chapter 6 with
> > curses support.
> >
> > 3- Bison can be removed, and built only once early in Chapter 6 (twice for
> > those who want to satisfy flex).
> >
> > 4- Flex can be removed, and built only once early in Chapter 6 (after bison,
> > and before the second build of bison for those who want to satisfy it).
>
> Then we need to move bison and flex before Chap. 6 binutils.
>
> > 5- Bzip2 can be removed since we're relying on host tools to decompress 
> > needed
> > packages that were downloaded early on (plus it will be built early on in
> > Chapter 6 so no package should require it).
> >
> > 6- I prefer to hostname over coreutils hostname but that's totally optional.
> >
> > 7- which can be added after coreutils (some packages may depend on it in the
> > format of using it inside scripts to fetch available binary versions (gcc 
> > with
> > go support, coreutils?, the Linux kernel (for testing?), but it's pretty
> > useful once you're in the chroot environment and in the final system as 
> > well).
> >
> > 8- Gettext can be removed and built early on in Chapter 6.
>
> We can't.  Glibc needs it to be built.
>
> > 9- Gzip can also be removed since we're relying on host tools to decompress
> > needed packages that were downloaded early on (plus it will be built early 
> > on
> > in Chapter 6 so no package should require it).
>
> Then we need to build it before bzip2, in Chap. 6.
>
> > 10- Perl can be completely removed and satisfied early on in Chapter 6 
> > before
> > packages that require it.
>
> We can't.  Glibc needs it to be built.
>
> > 11- Python can be removed? glibc requires it so it can't be removed, but 
> > with
> > other C libraries (e.g. musl) it can be removed and built only when needed 
> > in
> > Chapter 6.
>
> We can't.  Glibc needs it to be built.
>
> > 12- Texinfo can be removed and built early on in Chapter 6.
>
> We can't.  There is a circular dependency:
>
> * Groff needs Texinfo to build its documentation.
> * Texinfo must be installed after Perl, in Chap. 6 (or it would hardcode
> /tools/bin/perl into its executables).
> * Chap. 6 Perl needs Groff to build its man pages.
>
> > 13- Util-linux can be removed, but I think certain testing suites require 
> > it?
> > Perhaps for those who are sure that the packages have been built correctly 
> > it
> > can be removed?
>
> We can't.  There is a circular dependency between Util-linux libraries and
> Systemd/Eudev.
>
> > 14- Xz can be removed and built early on in Chapter 6 since we're relying on
> > host tools to decompress needed packages that were downloaded early on (plus
> > it will be built early on in Chapter 6 so no package should require it).
>
> We can't.  xz-5.2.5.tar.xz needs it to be untared.
>
> For 6 and 7, I really don't care.  I'll test 1-5, and 9 to see if they are
> possible.
> --
> Xi Ruoyao 
> School of Aerospace Sci

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

On Wed, May 6, 2020 at 1:56 PM Xi Ruoyao via lfs-dev
 wrote:
>
> On 2020-05-06 13:02 +0300, Firas Khalil Khana via lfs-dev wrote:
> > On Tue, May 5, 2020 at 6:40 PM Douglas R. Reno via lfs-dev
> >  wrote:
> > >
> > > On 5/5/20 5:49 AM, Firas Khalil Khana via lfs-dev wrote:
> > >
> > > @Xi,
> > >
> > > Thanks for taking the time to explain everything, much appreciated!
> > >
> > >
> > > > Then it will be stupidly inconvenience typing commands.
> > >
> > > It will still get you through until bash is rebuilt again in Chapter 6, 
> > > with
> > > no problems.
> > >
> > > That being said, I think Ncurses can't be dropped in Chapter 5 because
> > > Python in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc 
> > > to
> > > build).
> > >
> > >
> > > > There is some circular dependency between bison and gettext so it's
> > > > impossible
> > > > to build both of them only once.  It's #4634.
> > >
> > > I've checked this issue and it isn't related to what I've mentioned.
> > >
> > > I mentioned that the final list in Chapter 5 won't contain Bison, Gettext
> > > and Flex, but instead they will be rebuilt early on in Chapter 6 in 
> > > correct
> > > order (Gettext -> Bison -> Flex (-> Bison (Optional for the circular
> > > dependency)), so Bison will get to be built before Gettext and in Chapter 
> > > 6,
> > > so #4634 shouldn't appear.
> > >
> > > > Pierre just added them so Chap. 6 binutils can link to libfl.so.  It's
> > > > #4631.
> > >
> > > Again instead of adding more to Chapter 5, just reorder some packages in
> > > Chapter 6 to be built early on. In the list I've suggested, both Bison and
> > > Flex will be built before binutils so I don't see how #4631 will happen.
> > >
> > > > To avoid more ICA issues we don't want to move many things too "early".
> > >
> > > I'm afraid I'm not familiar with this term. I couldn't find it in the
> > > "Acronyms and Terms" appendix as well. You mean breakages?
> > >
> > >
> > > > Your distro your rules.
> > >
> > > I was just pointing out the existence of hostname (from debian), but 
> > > keeping
> > > coreutils the provider for hostname is better and more logical at this
> > > point.
> > >
> > >
> > > > Also #4634.
> > > Again, 4634 won't happen in the lists I've suggested. There will be no
> > > builds of Gettext, Bison and Flex in Chapter 5, and instead they'll be 
> > > built
> > > in the correct order and early on in Chapter 6 (Gettext -> Bison -> Flex 
> > > (->
> > > Bison for those who want to rebuild Bison again when Flex becomes
> > > available)).
> > > > We don't want many packages too be early in Chap. 6.
> > > Why not? Wouldn't it be better and easier to maintain if there were less
> > > packages to build, without sacrificing any package but just by simply
> > > reordering packages in Chapter 6? Not having to deal with cross packages
> > > (like Perl in Chapter 5, for example) is something good.
> > > > But we are using glibc. Again, your distro your rules.
> > > Yes, at this point Python can't be removed from Chapter 5 because it's
> > > needed by Glibc in Chapter 6 which is like the third package to be built
> > > there.
> > >
> > > > We don't want many packages too be early in Chap. 6.
> > > Again why not?
> > >
> > > > Wrong. Systemd or eudev depends on lib{uuid,blkid,mount}.so.
> > > Why add Util-linux to Chapter 5, instead of reordering Util-linux to be
> > > built before eudev in Chapter 6 then? Again as I said, I think you're 
> > > doing
> > > that to avoid #4637 so I won't argue, but it has to do with how these
> > > packages are configured (and that's not the point now).
> > >
> > > The other problem is that Util-Linux includes some support files (such as
> > > files that go in /usr/lib/tmpfiles.d), that are only installed if systemd 
> > > is
> > > present. However, systemd itself requires Util-Linux (similar to eudev I
> > > think, it uses it for libmount and libuuid). The way we've always resolved
> 

Re: [lfs-dev] Libcap 2.34 will not install .pc files in correct location

[Firas Khalil Khana via lfs-dev]

On Wed, May 6, 2020 at 12:25 AM Bruce Dubbs via lfs-dev <
lfs-dev@lists.linuxfromscratch.org> wrote:
>
> On 5/5/20 3:32 PM, Ken Moffat via lfs-dev wrote:
> > On Tue, May 05, 2020 at 07:41:58PM +0300, Firas Khalil Khana via
lfs-dev wrote:
> >> Confirming an issue is top-posting?
> >>
> >
> > Any post where the reply comes before the item to which you are
> > replying or commenting is top posting.
> >
> >> I didn't know that, and for that I apologize...
> >>
> >
> > So, here you have again top-posted by putting the text you are
> > replying to below your reply :
> >
> >> On Tue, 5 May 2020, 7:39 pm Bruce Dubbs via lfs-dev, <
> >> lfs-dev@lists.linuxfromscratch.org> wrote:
> >>
> >>> On 5/5/20 8:57 AM, Firas Khalil Khana via lfs-dev wrote:
> >>>> I can confirm this as well, and specifying
> >>>> "PKGCONFIGDIR=/usr/lib/pkgconfig" fixes the problem.
> >>>
> >>> Please stop top posting on the mailing lists.
>
> > In long replies it is sometimes polite to include introductory text
> > *after* the "On some day at some time, someone wrote" header, but
> > most text (even things as minimal as '+1' or 'me too') should still
> > go after the text to which you are replying.
> >
> > Unfortunately, gmail takes the microsoft approach and makes it
> > inconvenient to do this in its browser interface.
>
> To be honest, I top post for individual messages when the recient
> expects it.  The issue in top posting is that it doesn't work well for
> mailing lists, especially for threads with multiple posters.
>
> It is also good practice to delete portions of the message that are
> irrelevant to the reply.
>
>-- Bruce
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

I deeply apologize for the misunderstanding that happened. I confused the
terms "top-posting" with "bumping" and I thought that "top-posting" meant
to be the final/last person to reply to a certain ticket (since I've
replied to multiple tickets at the same time).
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

On Tue, May 5, 2020 at 6:40 PM Douglas R. Reno via lfs-dev
 wrote:
>
>
> On 5/5/20 5:49 AM, Firas Khalil Khana via lfs-dev wrote:
>
> @Xi,
>
> Thanks for taking the time to explain everything, much appreciated!
>
>
> > Then it will be stupidly inconvenience typing commands.
>
> It will still get you through until bash is rebuilt again in Chapter 6, with 
> no problems.
>
> That being said, I think Ncurses can't be dropped in Chapter 5 because Python 
> in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc to build).
>
>
> > There is some circular dependency between bison and gettext so it's 
> > impossible
>
> > to build both of them only once.  It's #4634.
>
> I've checked this issue and it isn't related to what I've mentioned.
>
> I mentioned that the final list in Chapter 5 won't contain Bison, Gettext and 
> Flex, but instead they will be rebuilt early on in Chapter 6 in correct order 
> (Gettext -> Bison -> Flex (-> Bison (Optional for the circular dependency)), 
> so Bison will get to be built before Gettext and in Chapter 6, so #4634 
> shouldn't appear.
>
> > Pierre just added them so Chap. 6 binutils can link to libfl.so.  It's 
> > #4631.
>
> Again instead of adding more to Chapter 5, just reorder some packages in 
> Chapter 6 to be built early on. In the list I've suggested, both Bison and 
> Flex will be built before binutils so I don't see how #4631 will happen.
>
> > To avoid more ICA issues we don't want to move many things too "early".
>
> I'm afraid I'm not familiar with this term. I couldn't find it in the 
> "Acronyms and Terms" appendix as well. You mean breakages?
>
>
> > Your distro your rules.
>
> I was just pointing out the existence of hostname (from debian), but keeping 
> coreutils the provider for hostname is better and more logical at this point.
>
>
> > Also #4634.
> Again, 4634 won't happen in the lists I've suggested. There will be no builds 
> of Gettext, Bison and Flex in Chapter 5, and instead they'll be built in the 
> correct order and early on in Chapter 6 (Gettext -> Bison -> Flex (-> Bison 
> for those who want to rebuild Bison again when Flex becomes available)).
> > We don't want many packages too be early in Chap. 6.
> Why not? Wouldn't it be better and easier to maintain if there were less 
> packages to build, without sacrificing any package but just by simply 
> reordering packages in Chapter 6? Not having to deal with cross packages 
> (like Perl in Chapter 5, for example) is something good.
> > But we are using glibc. Again, your distro your rules.
> Yes, at this point Python can't be removed from Chapter 5 because it's needed 
> by Glibc in Chapter 6 which is like the third package to be built there.
>
> > We don't want many packages too be early in Chap. 6.
> Again why not?
>
> > Wrong. Systemd or eudev depends on lib{uuid,blkid,mount}.so.
> Why add Util-linux to Chapter 5, instead of reordering Util-linux to be built 
> before eudev in Chapter 6 then? Again as I said, I think you're doing that to 
> avoid #4637 so I won't argue, but it has to do with how these packages are 
> configured (and that's not the point now).
>
> The other problem is that Util-Linux includes some support files (such as 
> files that go in /usr/lib/tmpfiles.d), that are only installed if systemd is 
> present. However, systemd itself requires Util-Linux (similar to eudev I 
> think, it uses it for libmount and libuuid). The way we've always resolved 
> that is to build Util-Linux in Chapter 5 (previously there were more packages 
> that required it), and then build systemd, and then rebuild Util-Linux 
> afterwards.
>
> - Doug
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

Then why is Util-linux also included in Chapter 5 in the SysVinit
version of LFS? Shouldn't it suffice to only have it be built in
Chapter 6?
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Libcap 2.34 will not install .pc files in correct location

[Firas Khalil Khana via lfs-dev]

Confirming an issue is top-posting?

I didn't know that, and for that I apologize...

On Tue, 5 May 2020, 7:39 pm Bruce Dubbs via lfs-dev, <
lfs-dev@lists.linuxfromscratch.org> wrote:

> On 5/5/20 8:57 AM, Firas Khalil Khana via lfs-dev wrote:
> > I can confirm this as well, and specifying
> > "PKGCONFIGDIR=/usr/lib/pkgconfig" fixes the problem.
>
> Please stop top posting on the mailing lists.
>
>-- Bruce
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Add missing space...

[Firas Khalil Khana via lfs-dev]

For the sake of completeness, there's a missing space in Chapter 6, in
E2fsprogs, and when listing Installed programs (between dumpe2fs and
e2freefrag):

"Installed programs:
... debugfs, dumpe2fs,e2freefrag, e2fsck ..."

When it should be:

"Installed programs:
... debugfs, dumpe2fs, e2freefrag, e2fsck ..."
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

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

[Firas Khalil Khana via lfs-dev]

Well actually both of "libtool" and "autoconf" in Chapter 6 require
"help2man" to be available beforehand (I believe also "binutils" expects
"help2man" to be available as well).

I don't see a reason for not adding the dedicated "help2man" instead of
passing "HELP2MAN=true".

"help2man" expects "makeinfo" (from "texinfo") to be available beforehand,
so it should be built after "texinfo" is built".
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Libcap 2.34 will not install .pc files in correct location

[Firas Khalil Khana via lfs-dev]

I can confirm this as well, and specifying
"PKGCONFIGDIR=/usr/lib/pkgconfig" fixes the problem.

On Tue, May 5, 2020 at 3:26 PM Ryan Marsaw via lfs-dev <
lfs-dev@lists.linuxfromscratch.org> wrote:

> Hello all.
>
> Even though Libcap 2.34 has not yet been updated in the LFS book, this
> is just a heads up:
>
> Libcap 2.34 installs the pkgconfig directory under /lib (and not
> /usr/lib as in previous versions).
>
> I diffed the top-level Make.Rules file from both libcap 2.33 and 2.34
> and noticed this:
>
> [...]
> < PKGCONFIGDIR=$(prefix)/$(lib)/pkgconfig
> ---
> > PKGCONFIGDIR=$(LIBDIR)/pkgconfig
> [...]
>
> It looks like the line that installs the package will need to be
> adjusted:
>
> make lib=lib PKGCONFIGDIR=/usr/lib/pkgconfig install
>
> Cheers,
>
> --Ryan
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

> So I see you point is to reorder the packages in Chap. 6 to reduce
packages in
> Chap. 5.  But I still believe we shouldn't put many packages to before
final
> GCC.  That may cause ICA failures.

Precisely! And I've managed to compiler everything from start to finish
with no
errors (didn't run the testing suites).

> ICA means Iterative Comparison Analysis.  As Pierre said in #4624:

> > ICA (Iterative comparison analysis) allows to compare several builds of
LFS,
> > each build being done with the system built during the previous build.
If some
> > dependency or action was missing on first built and available on
followings,
> > it shows up immediately.
> >
> > Whether lfs should be able to rebuild itself completely identical is
maybe not
> > necessary, but if the second build is too different from the first, it
may be
> > a indication of incorrectness.
> >
> > Leaving priority and severity to normal. It will be adjusted depending
on what
> > is found.
> >
> > Note that what we have allows building the whole blfs, so it is
unlikely that
> > priority and severity go the "high" direction.

Thanks for taking the time to explain, it would be interesting to do an ICA
on this new
order then.

> I should try your approach and do an ICA, and see what will happen.  But
I'm now
> busy preparing the problem set for an online programming contest.  Maybe
I'll
> have time to do this on May 20.

Please do, it'll be really interesting to see if it works for everyone as
well with no problems,
and it should make stuff easier for both the learner and the maintainer.

Good luck with your contest!

Thanks again for your time and effort.

Sincerely,
Firas Khalil Khana


On Tue, May 5, 2020 at 2:57 PM Xi Ruoyao via lfs-dev <
lfs-dev@lists.linuxfromscratch.org> wrote:

> On 2020-05-05 13:49 +0300, Firas Khalil Khana via lfs-dev wrote:
> > @Xi,
> >
> > Thanks for taking the time to explain everything, much appreciated!
> >
> >
> > > Then it will be stupidly inconvenience typing commands.
> >
> > It will still get you through until bash is rebuilt again in Chapter 6,
> with
> > no problems.
> >
> > That being said, I think Ncurses can't be dropped in Chapter 5 because
> Python
> > in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc to
> build).
> >
> >
> > > There is some circular dependency between bison and gettext so it's
> > impossible
> > > to build both of them only once.  It's #4634.
> > I've checked this issue and it isn't related to what I've mentioned.
> > I mentioned that the final list in Chapter 5 won't contain Bison,
> Gettext and
> > Flex, but instead they will be rebuilt early on in Chapter 6 in correct
> order
> > (Gettext -> Bison -> Flex (-> Bison (Optional for the circular
> dependency)),
> > so Bison will get to be built before Gettext and in Chapter 6, so #4634
> > shouldn't appear.
> >
> > > Pierre just added them so Chap. 6 binutils can link to libfl.so.  It's
> > #4631.
> > Again instead of adding more to Chapter 5, just reorder some packages in
> > Chapter 6 to be built early on. In the list I've suggested, both Bison
> and
> > Flex will be built before binutils so I don't see how #4631 will happen.
> >
> > > To avoid more ICA issues we don't want to move many things too "early".
> > I'm afraid I'm not familiar with this term. I couldn't find it in the
> > "Acronyms and Terms" appendix as well. You mean breakages?
> >
> >
> > > Your distro your rules.
> > I was just pointing out the existence of hostname (from debian), but
> keeping
> > coreutils the provider for hostname is better and more logical at this
> point.
> >
> >
> > > Also #4634.
> > Again, 4634 won't happen in the lists I've suggested. There will be no
> builds
> > of Gettext, Bison and Flex in Chapter 5, and instead they'll be built in
> the
> > correct order and early on in Chapter 6 (Gettext -> Bison -> Flex (->
> Bison
> > for those who want to rebuild Bison again when Flex becomes available)).
> >
> > > We don't want many packages too be early in Chap. 6.
> > Why not? Wouldn't it be better and easier to maintain if there were less
> > packages to build, without sacrificing any package but just by simply
> > reordering packages in Chapter 6? Not having to deal with cross packages
> (like
> > Perl in Chapter 5, for example) is something good.
> >
> > > But we 

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

@Xi,

Thanks for taking the time to explain everything, much appreciated!


> Then it will be stupidly inconvenience typing commands.

It will still get you through until bash is rebuilt again in Chapter 6,
with no problems.

That being said, I think Ncurses can't be dropped in Chapter 5 because
Python in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc
to build).


> There is some circular dependency between bison and gettext so it's
impossible

> to build both of them only once.  It's #4634.

I've checked this issue and it isn't related to what I've mentioned.

I mentioned that the final list in Chapter 5 won't contain Bison,
Gettext and Flex, but instead they will be rebuilt early on in Chapter
6 in correct order (Gettext -> Bison -> Flex (-> Bison (Optional for
the circular dependency)), so Bison will get to be built before
Gettext and in Chapter 6, so #4634 shouldn't appear.


> Pierre just added them so Chap. 6 binutils can link to libfl.so.  It's #4631.

Again instead of adding more to Chapter 5, just reorder some packages
in Chapter 6 to be built early on. In the list I've suggested, both
Bison and Flex will be built before binutils so I don't see how #4631
will happen.


> To avoid more ICA issues we don't want to move many things too "early".

I'm afraid I'm not familiar with this term. I couldn't find it in the
"Acronyms and Terms" appendix as well. You mean breakages?


> Your distro your rules.

I was just pointing out the existence of hostname (from debian), but
keeping coreutils the provider for hostname is better and more logical at
this point.


> Also #4634.
Again, 4634 won't happen in the lists I've suggested. There will be no
builds of Gettext, Bison and Flex in Chapter 5, and instead they'll be
built in the correct order and early on in Chapter 6 (Gettext -> Bison ->
Flex (-> Bison for those who want to rebuild Bison again when Flex becomes
available)).

> We don't want many packages too be early in Chap. 6.
Why not? Wouldn't it be better and easier to maintain if there were less
packages to build, without sacrificing any package but just by simply
reordering packages in Chapter 6? Not having to deal with cross packages
(like Perl in Chapter 5, for example) is something good.

> But we are using glibc. Again, your distro your rules.
Yes, at this point Python can't be removed from Chapter 5 because it's
needed by Glibc in Chapter 6 which is like the third package to be built
there.

> We don't want many packages too be early in Chap. 6.
Again why not?

> Wrong. Systemd or eudev depends on lib{uuid,blkid,mount}.so.
Why add Util-linux to Chapter 5, instead of reordering Util-linux to be
built before eudev in Chapter 6 then? Again as I said, I think you're doing
that to avoid #4637 so I won't argue, but it has to do with how these
packages are configured (and that's not the point now).

> How to untar xz-5.2.5.tar.xz itself in Chap. 6?
I apologize for missing that, xz then should remain in Chapter 5, but the
user can be instructed to extract this sole package before entering the
chroot environment by relying on the host's xz.

> It's not "the faster the better". If "the faster the better" we can just
cross-

> compile everything in host, and put them altogether.

I never said that "the faster the better". A cross compiler can only
get you so far, as it's mostly for embedded stuff. Anything more
complicated than that would cause stuff from the host to leak in,
which is why I think LFS's approach (using a separate user, having
temporary tools in a chroot environment...) is a good way to achieve
maximum isolation from the host.

I was just pointing out that a simple reorder might make things
easier, and somewhat faster, and might as well remove some headache to
maintainers at this point.


Thanks again for taking the time to reply to my proposals.


Keep up the great work!


Sincerely,

Firas Khalil Khana




On Tue, May 5, 2020 at 1:12 PM Firas Khalil Khana 
wrote:

> @Ken,
>
> Thanks for your much appreciated response!
>
> I'm not talking about any particular plans. I'm not changing anything in
> the way LFS is being built.
>
> I'm just removing packages from the temporary tools in Chapter 5 that
> aren't needed in Chapter 6 because they'll
> be built again there.
>
> Regarding which, then are we seriously talking about bloatware when most
> of the stuff used is from GNU? I'm just
> saying that to make things more complete (since LFS uses GNU Glibc, GNU
> coreutils, GNU findutils, GNU diffutils...)
> then why not include GNU which as well as?
>
> Thanks for pointing out that BLFS has a which alternative.
>
> Keep up the great work!
>
> On Mon, May 4, 2020 at 8:39 PM Firas Khalil Khana 
> wrote:
>
>> Hey there,
>>
>> My name is Firas Khalil Khana, and I'm the creator of glaucus
>> .
>>
>> I'd like to salute your efforts for keeping this project awesome this
>> whole time! The shear amount of information in a single place like LFS is
>> truly impr

Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

@Ken,

Thanks for your much appreciated response!

I'm not talking about any particular plans. I'm not changing anything in
the way LFS is being built.

I'm just removing packages from the temporary tools in Chapter 5 that
aren't needed in Chapter 6 because they'll
be built again there.

Regarding which, then are we seriously talking about bloatware when most of
the stuff used is from GNU? I'm just
saying that to make things more complete (since LFS uses GNU Glibc, GNU
coreutils, GNU findutils, GNU diffutils...)
then why not include GNU which as well as?

Thanks for pointing out that BLFS has a which alternative.

Keep up the great work!

On Mon, May 4, 2020 at 8:39 PM Firas Khalil Khana 
wrote:

> Hey there,
>
> My name is Firas Khalil Khana, and I'm the creator of glaucus
> .
>
> I'd like to salute your efforts for keeping this project awesome this
> whole time! The shear amount of information in a single place like LFS is
> truly impressive.
>
> That being said, I'd like to propose a (somewhat) slight change regarding
> the amount of packages actually needed in the temporary system (Chapter 5,
> which I'll be referring to as the chroot environment).
>
> I'd also like to propose a reordering of some packages in the basic system
> software (Chapter 6) to conform with the unneeded packages in the chroot
> environment.
>
> Please keep in mind that these proposals weren't tested with the
> testing/checking suites.
>
> Starting with the first proposal in Chapter 5, and after skipping Tcl,
> Expect and DejaGNU, we can say:
> 1- Ncurses can be removed? or is it needed for Chapter 5 Python which in
> turn is needed for Chapter 6 Glibc? Perhaps it can be removed for those
> using different C libraries (e.g. musl)?
>
> 2- Bash (The chroot environment's shell) can be built without curses
> support by passing "--without-curses", until it gets rebuilt again in
> Chapter 6 with curses support.
>
> 3- Bison can be removed, and built only once early in Chapter 6 (twice for
> those who want to satisfy flex).
>
> 4- Flex can be removed, and built only once early in Chapter 6 (after
> bison, and before the second build of bison for those who want to satisfy
> it).
>
> 5- Bzip2 can be removed since we're relying on host tools to decompress
> needed packages that were downloaded early on (plus it will be built early
> on in Chapter 6 so no package should require it).
>
> 6- I prefer to hostname
>  
> over
> coreutils hostname but that's totally optional.
>
> 7- which  can be added
> after coreutils (some packages may depend on it in the format of using it
> inside scripts to fetch available binary versions (gcc with go support,
> coreutils?, the Linux kernel (for testing?), but it's pretty useful once
> you're in the chroot environment and in the final system as well).
>
> 8- Gettext can be removed and built early on in Chapter 6.
>
> 9- Gzip can also be removed since we're relying on host tools to
> decompress needed packages that were downloaded early on (plus it will be
> built early on in Chapter 6 so no package should require it).
>
> 10- Perl can be completely removed and satisfied early on in Chapter 6
> before packages that require it.
>
> 11- Python can be removed? glibc requires it so it can't be removed, but
> with other C libraries (e.g. musl) it can be removed and built only when
> needed in Chapter 6.
>
> 12- Texinfo can be removed and built early on in Chapter 6.
>
> 13- Util-linux can be removed, but I think certain testing suites require
> it? Perhaps for those who are sure that the packages have been built
> correctly it can be removed?
>
> 14- Xz can be removed and built early on in Chapter 6 since we're relying
> on host tools to decompress needed packages that were downloaded early on
> (plus it will be built early on in Chapter 6 so no package should require
> it).
>
> So we'll end up with the following list of packages for Chapter 5
> (following DejaGNU):
> 1- M4
> 2- Ncurses [Glibc only]
> 3- Bash
> 4- Coreutils
> 5- Diffutils
> 6- File
> 7- Findutils
> 8- Gawk
> 9- Grep
> 10- Make
> 11- Patch
> 12- Python [Glibc only]
> 13- Sed
> 14- Tar
>
> Regarding Chapter 6, the packages that we've removed from Chapter 5 and
> are needed here can be built early on (immediately after adjusting the
> toolchain, and before Chapter 6 Zlib):
>
> 1. GDBM
> 2. Gperf
> 3. Perl
> 4. Texinfo
> 5. help2man (this can be added to satisfy packages that require it like
> binutils, libtool, autoconf..., and is better than specifying
> "MAKEINFO=true")
> 6. Expat
> 7. XML::Parser
> 8. Libtool
> 9. Autoconf
> 10. Automake
> 11. Gettext
> 12. Bison
> 13. Ncurses
> 14. Bash
>
> and then continuing from Zlib to the end while removing the packages
> specified above because they were built beforehand (with the exception of
> bison for those who want to build it a second time afte

[lfs-dev] Reduce Temporary System Components and Reorder Basic System Software

[Firas Khalil Khana via lfs-dev]

Hey there,

My name is Firas Khalil Khana, and I'm the creator of glaucus
.

I'd like to salute your efforts for keeping this project awesome this whole
time! The shear amount of information in a single place like LFS is truly
impressive.

That being said, I'd like to propose a (somewhat) slight change regarding
the amount of packages actually needed in the temporary system (Chapter 5,
which I'll be referring to as the chroot environment).

I'd also like to propose a reordering of some packages in the basic system
software (Chapter 6) to conform with the unneeded packages in the chroot
environment.

Please keep in mind that these proposals weren't tested with the
testing/checking suites.

Starting with the first proposal in Chapter 5, and after skipping Tcl,
Expect and DejaGNU, we can say:
1- Ncurses can be removed? or is it needed for Chapter 5 Python which in
turn is needed for Chapter 6 Glibc? Perhaps it can be removed for those
using different C libraries (e.g. musl)?

2- Bash (The chroot environment's shell) can be built without curses
support by passing "--without-curses", until it gets rebuilt again in
Chapter 6 with curses support.

3- Bison can be removed, and built only once early in Chapter 6 (twice for
those who want to satisfy flex).

4- Flex can be removed, and built only once early in Chapter 6 (after
bison, and before the second build of bison for those who want to satisfy
it).

5- Bzip2 can be removed since we're relying on host tools to decompress
needed packages that were downloaded early on (plus it will be built early
on in Chapter 6 so no package should require it).

6- I prefer to hostname

over
coreutils hostname but that's totally optional.

7- which  can be added
after coreutils (some packages may depend on it in the format of using it
inside scripts to fetch available binary versions (gcc with go support,
coreutils?, the Linux kernel (for testing?), but it's pretty useful once
you're in the chroot environment and in the final system as well).

8- Gettext can be removed and built early on in Chapter 6.

9- Gzip can also be removed since we're relying on host tools to decompress
needed packages that were downloaded early on (plus it will be built early
on in Chapter 6 so no package should require it).

10- Perl can be completely removed and satisfied early on in Chapter 6
before packages that require it.

11- Python can be removed? glibc requires it so it can't be removed, but
with other C libraries (e.g. musl) it can be removed and built only when
needed in Chapter 6.

12- Texinfo can be removed and built early on in Chapter 6.

13- Util-linux can be removed, but I think certain testing suites require
it? Perhaps for those who are sure that the packages have been built
correctly it can be removed?

14- Xz can be removed and built early on in Chapter 6 since we're relying
on host tools to decompress needed packages that were downloaded early on
(plus it will be built early on in Chapter 6 so no package should require
it).

So we'll end up with the following list of packages for Chapter 5
(following DejaGNU):
1- M4
2- Ncurses [Glibc only]
3- Bash
4- Coreutils
5- Diffutils
6- File
7- Findutils
8- Gawk
9- Grep
10- Make
11- Patch
12- Python [Glibc only]
13- Sed
14- Tar

Regarding Chapter 6, the packages that we've removed from Chapter 5 and are
needed here can be built early on (immediately after adjusting the
toolchain, and before Chapter 6 Zlib):

1. GDBM
2. Gperf
3. Perl
4. Texinfo
5. help2man (this can be added to satisfy packages that require it like
binutils, libtool, autoconf..., and is better than specifying
"MAKEINFO=true")
6. Expat
7. XML::Parser
8. Libtool
9. Autoconf
10. Automake
11. Gettext
12. Bison
13. Ncurses
14. Bash

and then continuing from Zlib to the end while removing the packages
specified above because they were built beforehand (with the exception of
bison for those who want to build it a second time after flex).

This can help by greatly reducing the amount of time needed to get the
final system working, and should make things for some packages (perl and
python) easier since they're only built once in the final system when
needed (the final builds should also theoretically be easier because
they're native builds now, removing the need to deal with cross builds of
these packages especially when using other C libraries (e.g. musl)).

This also makes Autotools available early on in Chapter 6 in case running
"autoreconf", "./autogen.sh", "./bootstrap.sh"... (whatever scripts were
called) was needed (patches that include source modifications usually
require that).

I'd like to thank you again for all the time and effort you've put in this
project.

Keep up the great work!

Sincerely,
Firas Khalil Khana
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe