Re: [lfs-dev] Inaccuracy in chroot page
Am Samstag, den 14.03.2020, 18:11 +0100 schrieb 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. I agree, i think bash not even know that its running in chroot. > Anyway, nobody has complained for > years, let's not change anything. It does not prevent the build to work. also true > 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
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
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/ -- Bruce -- 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
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] Inaccuracy in chroot page
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. -- Bruce -- 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
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
Re: [lfs-dev] Ordering of Chapter 5 GGC Pass2 required external packages stanza
On 2020-03-14 16:56 +0800, Kevin Buckley via lfs-dev wrote: > 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 There is no reason. We can resort them if we want. > 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: GCC 9.3.0 has been released and we'll update to it. Then this workaround will be deleted anyway. -- 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
[lfs-dev] Ordering of Chapter 5 GGC Pass2 required external packages stanza
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: Hoping that's thought useful: Kevin -- 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?
On Thu, 12 Mar 2020 at 16:45, Pierre Labastie via lfs-dev wrote: > > 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 > - Yep that works, without needing to echo anything into any files Cheers. -- 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
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
