Re: [lfs-dev] incorrect note about libstdc++ in toolchain technical notes?
在 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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] incorrect note about libstdc++ in toolchain technical notes?
> "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. -- 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
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote: > On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote: > > On 6/20/20 8:30 PM, Bruce Dubbs wrote: > > > On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: > > > > On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: > > > > > On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: > > > > > > The discussion with Frans de Boer in lfs-support shown that the > > > > > > environment > > > > > > variables from host can catch us completely off guard. Though in > > > > > > his case > > > > > > the > > > > > > problem is that he forgot to create /home/lfs/.bash_profile, > > > > > > normally > > > > > > /etc/bash.bashrc would be more dangerous (the book has no > > > > > > consideration of > > > > > > this > > > > > > file), and used by many distros. > > > > > > > > > > > > So if there is no objection I'll commit the change we've discussed > > > > > > in last > > > > > > Nov.: > > > > > > > > > > > > /home/lfs/.bash_profile: > > > > > > > > > > > > exec env -i ENV=$HOME/.lfs_bashrc \ > > > > > > HOME=$HOME\ > > > > > > TERM=$TERM\ > > > > > > PS1='\u:\w\$ '\ > > > > > > /bin/bash --posix > > > > > > > > > > > > /home/lfs/.lfs_bashrc: > > > > > > > > > > > > set +o posix > > > > > > set +h > > > > > > umask 022 > > > > > > LFS=/mnt/lfs > > > > > > LC_ALL=POSIX > > > > > > LFS_TGT=$(uname -m)-lfs-linux-gnu > > > > > > PATH=/usr/bin > > > > > > if [ ! -L /bin ]; then PATH=/bin:$PATH; fi > > > > > > PATH=$LFS/tools/bin:$PATH > > > > > > export LFS LC_ALL LFS_TGT PATH > > > > > > > > > > So the --posix in .bash_profile allows the use of > > > > > ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns > > > > > posix > > > > > mode off? > > > > > > > > > > At a minimum this looks like a hack that needs a fair amount of > > > > > explanation. > > > > > > > > > > The reason for this is because a user forgot to create .bash_profile? > > > > > In that case the above doesn't work. > > > > > > > > The discussion just proved that environment variables from host are > > > > really > > > > harmful. > > > > > > > > > From https://sources.debian.org/src/bash/5.0-6/debian/README/ > > > > > > > > > > 5. What is /etc/bash.bashrc? It doesn't seem to be documented. > > > > > > > > > > The Debian version of bash is compiled with a special option > > > > > (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before > > > > > ~/.bashrc > > > > > for interactive non-login shells. So, on Debian systems, > > > > > /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to > > > > > ~/.bash_profile. > > > > > > > > > > When I look at a debian system's /etc/bash.bashrc, I don't see what > > > > > would affect what we have now. What was the reported problem? > > > > > > > > > > We've been using the current structure for a long time without a > > > > > reported issue. What's new? > > > > > > > > I studied OpenSUSE bash.bashrc a little. It's a giant monster script > > > > (even > > > > sourcing some scripts from /etc/profile.d) so I won't be suprised if > > > > one day a > > > > bash.bashrc breaks some package. > > > > > > > > And after a sleep I realized a more serious issue: if some distro has a > > > > /usr/share/config.site (or /usr/etc/config.site, which is not FHS and > > > > shouldn't > > > > exist), it would be used by autotools configure script *even if we are > > > > cross > > > > compiling*, and break temporary glibc build. Perhaps we should "export > > > > CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. > > > > > > I wrote the above before I saw the messages in -support. I do note that > > > in my debian system I used to get LFS up on my new system I edited > > > /etc/bash.bashrc so the first line was 'return'. I did that primarily > > > because I don't like polluting the environment with bash completion stuff. > > > > > > I think the problem is not 'exec env ... /bin/bash' directly, but the > > > changes to bash invocation by some distros. > > > > > > I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. > > > I'll do a test of that. > > > > I tested several options. That /etc/bash.bashrc thing is evil. I > > edited it to put at the top: echo "IN /etc/bash.bashrc" > > > > Even with your line > > > > exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' > > /bin/bash --posix > > > > (Note that I changed the file name to make it a non-hidden file.) > > > > it STILL runs bash.bashrc. --norc doesn't change that either. Nor does > > --init-file $HOME/lfs-bashrc > > > > In the case if ubuntu though the posix setting does not install the > > function command_not_found_handle, but I don't think we can really count > > on that. > > > > Really the I think the only way to handle this is t
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/20/20 8:30 PM, Bruce Dubbs wrote: > > On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: > > > On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: > > > > On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: > > > > > The discussion with Frans de Boer in lfs-support shown that the > > > > > environment > > > > > variables from host can catch us completely off guard. Though in > > > > > his case > > > > > the > > > > > problem is that he forgot to create /home/lfs/.bash_profile, normally > > > > > /etc/bash.bashrc would be more dangerous (the book has no > > > > > consideration of > > > > > this > > > > > file), and used by many distros. > > > > > > > > > > So if there is no objection I'll commit the change we've discussed > > > > > in last > > > > > Nov.: > > > > > > > > > > /home/lfs/.bash_profile: > > > > > > > > > > exec env -i ENV=$HOME/.lfs_bashrc \ > > > > > HOME=$HOME\ > > > > > TERM=$TERM\ > > > > > PS1='\u:\w\$ '\ > > > > > /bin/bash --posix > > > > > > > > > > /home/lfs/.lfs_bashrc: > > > > > > > > > > set +o posix > > > > > set +h > > > > > umask 022 > > > > > LFS=/mnt/lfs > > > > > LC_ALL=POSIX > > > > > LFS_TGT=$(uname -m)-lfs-linux-gnu > > > > > PATH=/usr/bin > > > > > if [ ! -L /bin ]; then PATH=/bin:$PATH; fi > > > > > PATH=$LFS/tools/bin:$PATH > > > > > export LFS LC_ALL LFS_TGT PATH > > > > > > > > So the --posix in .bash_profile allows the use of > > > > ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix > > > > mode off? > > > > > > > > At a minimum this looks like a hack that needs a fair amount of > > > > explanation. > > > > > > > > The reason for this is because a user forgot to create .bash_profile? > > > > In that case the above doesn't work. > > > > > > The discussion just proved that environment variables from host are > > > really > > > harmful. > > > > > > > From https://sources.debian.org/src/bash/5.0-6/debian/README/ > > > > > > > > 5. What is /etc/bash.bashrc? It doesn't seem to be documented. > > > > > > > > The Debian version of bash is compiled with a special option > > > > (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before > > > > ~/.bashrc > > > > for interactive non-login shells. So, on Debian systems, > > > > /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to > > > > ~/.bash_profile. > > > > > > > > When I look at a debian system's /etc/bash.bashrc, I don't see what > > > > would affect what we have now. What was the reported problem? > > > > > > > > We've been using the current structure for a long time without a > > > > reported issue. What's new? > > > > > > I studied OpenSUSE bash.bashrc a little. It's a giant monster script > > > (even > > > sourcing some scripts from /etc/profile.d) so I won't be suprised if > > > one day a > > > bash.bashrc breaks some package. > > > > > > And after a sleep I realized a more serious issue: if some distro has a > > > /usr/share/config.site (or /usr/etc/config.site, which is not FHS and > > > shouldn't > > > exist), it would be used by autotools configure script *even if we are > > > cross > > > compiling*, and break temporary glibc build. Perhaps we should "export > > > CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. > > > > I wrote the above before I saw the messages in -support. I do note that > > in my debian system I used to get LFS up on my new system I edited > > /etc/bash.bashrc so the first line was 'return'. I did that primarily > > because I don't like polluting the environment with bash completion stuff. > > > > I think the problem is not 'exec env ... /bin/bash' directly, but the > > changes to bash invocation by some distros. > > > > I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. > > I'll do a test of that. > > I tested several options. That /etc/bash.bashrc thing is evil. I > edited it to put at the top: echo "IN /etc/bash.bashrc" > > Even with your line > > exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' > /bin/bash --posix > > (Note that I changed the file name to make it a non-hidden file.) > > it STILL runs bash.bashrc. --norc doesn't change that either. Nor does > --init-file $HOME/lfs-bashrc > > In the case if ubuntu though the posix setting does not install the > function command_not_found_handle, but I don't think we can really count > on that. > > Really the I think the only way to handle this is to edit > /etc/bash.bashrc to put a return in on the first line or to rename the > file and let the user restore it if desired later. It's strange. I read bash code and commit history but found --norc should disable loading of SYS_BASHRC, since bash-2.0. It also really works on latest Arch (but it didn't
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 8:30 PM, Bruce Dubbs wrote: On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME \ TERM=$TERM \ PS1='\u:\w\$ ' \ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. I tested several options. That /etc/bash.bashrc thing is evil. I edited it to put at the top: echo "IN /etc/bash.bashrc" Even with your line exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --posix (Note that I changed the file name to make it a non-hidden file.) it STILL runs bash.bashrc. --norc doesn't change that either. Nor does --init-file $HOME/lfs-bashrc In the case if ubuntu though the posix setting does not install the function command_not_found_handle, but I don't think we can really count on that. Really the I think the only way to handle this is to edit /etc/bash.bashrc to put a return in on the first line or to rename the file and let the user restore it if desired later. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote: On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. I wrote the above before I saw the messages in -support. I do note that in my debian system I used to get LFS up on my new system I edited /etc/bash.bashrc so the first line was 'return'. I did that primarily because I don't like polluting the environment with bash completion stuff. I think the problem is not 'exec env ... /bin/bash' directly, but the changes to bash invocation by some distros. I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work. I'll do a test of that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: > > The discussion with Frans de Boer in lfs-support shown that the environment > > variables from host can catch us completely off guard. Though in his case > > the > > problem is that he forgot to create /home/lfs/.bash_profile, normally > > /etc/bash.bashrc would be more dangerous (the book has no consideration of > > this > > file), and used by many distros. > > > > So if there is no objection I'll commit the change we've discussed in last > > Nov.: > > > > /home/lfs/.bash_profile: > > > > exec env -i ENV=$HOME/.lfs_bashrc \ > > HOME=$HOME\ > > TERM=$TERM\ > > PS1='\u:\w\$ '\ > > /bin/bash --posix > > > > /home/lfs/.lfs_bashrc: > > > > set +o posix > > set +h > > umask 022 > > LFS=/mnt/lfs > > LC_ALL=POSIX > > LFS_TGT=$(uname -m)-lfs-linux-gnu > > PATH=/usr/bin > > if [ ! -L /bin ]; then PATH=/bin:$PATH; fi > > PATH=$LFS/tools/bin:$PATH > > export LFS LC_ALL LFS_TGT PATH > > So the --posix in .bash_profile allows the use of > ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix > mode off? > > At a minimum this looks like a hack that needs a fair amount of explanation. > > The reason for this is because a user forgot to create .bash_profile? > In that case the above doesn't work. The discussion just proved that environment variables from host are really harmful. > From https://sources.debian.org/src/bash/5.0-6/debian/README/ > > 5. What is /etc/bash.bashrc? It doesn't seem to be documented. > > The Debian version of bash is compiled with a special option > (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc > for interactive non-login shells. So, on Debian systems, > /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to > ~/.bash_profile. > > When I look at a debian system's /etc/bash.bashrc, I don't see what > would affect what we have now. What was the reported problem? > > We've been using the current structure for a long time without a > reported issue. What's new? I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a bash.bashrc breaks some package. And after a sleep I realized a more serious issue: if some distro has a /usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't exist), it would be used by autotools configure script *even if we are cross compiling*, and break temporary glibc build. Perhaps we should "export CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it. -- 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
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote: The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH So the --posix in .bash_profile allows the use of ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix mode off? At a minimum this looks like a hack that needs a fair amount of explanation. The reason for this is because a user forgot to create .bash_profile? In that case the above doesn't work. From https://sources.debian.org/src/bash/5.0-6/debian/README/ 5. What is /etc/bash.bashrc? It doesn't seem to be documented. The Debian version of bash is compiled with a special option (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc for interactive non-login shells. So, on Debian systems, /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to ~/.bash_profile. When I look at a debian system's /etc/bash.bashrc, I don't see what would affect what we have now. What was the reported problem? We've been using the current structure for a long time without a reported issue. What's new? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
The discussion with Frans de Boer in lfs-support shown that the environment variables from host can catch us completely off guard. Though in his case the problem is that he forgot to create /home/lfs/.bash_profile, normally /etc/bash.bashrc would be more dangerous (the book has no consideration of this file), and used by many distros. So if there is no objection I'll commit the change we've discussed in last Nov.: /home/lfs/.bash_profile: exec env -i ENV=$HOME/.lfs_bashrc \ HOME=$HOME\ TERM=$TERM\ PS1='\u:\w\$ '\ /bin/bash --posix /home/lfs/.lfs_bashrc: set +o posix set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/usr/bin if [ ! -L /bin ]; then PATH=/bin:$PATH; fi PATH=$LFS/tools/bin:$PATH export LFS LC_ALL LFS_TGT PATH -- 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
Re: [lfs-dev] perl install options
On Sat, Jun 20, 2020 at 07:05:24AM -0700, Joel Bion via lfs-dev wrote: > Upgrading Perl was the trigger for me building my own package dependency > tracker utility. With tons of manual configuration, I am able to upgrade any > subset of packages at one time. It tells me what I need to rebuild, in what > order. Some packages trigger no or few rebuilds. Others, like OpenSSL, > trigger a few dozen. Python 3 might trigger 100. Perl is crazy; it triggers > 100s. > > Each package has a build script I’ve written. If I ever get around to it, > I’ll make it generate a super-script that involves unpacking the tar files, > so I can just automate the whole build. > > Sent from my iPhone > I won't complain about top-posting in the light of that last line! You must build a _lot_ more than I do: I've got several non-book perl modules which I sometimes build, and there are a few modules in the book which I never build, but in the perl directory of my scripts I only have 150 modules. For python, I haven't counted recently (they only should need to be rebuilt when the minor version changes, I believe). And for openssl I don't rebuild anything if the version (without the letter) has not changed, e.g. 1.1.f to 1.1.1g. But I do stop and start anything which is running and linked to the old version. I normally echo this as one long line at the end of my script, with a message to copy and paste it to see what needs to be bounced: grep -l -e 'libssl.*deleted' -e 'libcrypto.*deleted' /proc/*/maps | tr -cd 0-9\\\n | xargs -r ps u ĸen -- He died at the console, of hunger and thirst. Next day he was buried, face-down, nine-edge first. - the perfect programmer -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] perl install options
Upgrading Perl was the trigger for me building my own package dependency
tracker utility. With tons of manual configuration, I am able to upgrade any
subset of packages at one time. It tells me what I need to rebuild, in what
order. Some packages trigger no or few rebuilds. Others, like OpenSSL, trigger
a few dozen. Python 3 might trigger 100. Perl is crazy; it triggers 100s.
Each package has a build script I’ve written. If I ever get around to it, I’ll
make it generate a super-script that involves unpacking the tar files, so I can
just automate the whole build.
Sent from my iPhone
> On Jun 20, 2020, at 6:54 AM, Ken Moffat via lfs-dev
> wrote:
>
> On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
>> Hi all,
>>
>> this is about hte configuration options of perl.
>>
>> Problem:
>> whenever perl is upgraded to a newer version (for example 5.30.2 to
>> 5.30.3), all perl modules needs to be reinstalled as the current
>> configuration of perl forces a directory structure like
>>
>> /usr
>> /lib
>>/perl5
>> /5.30.2
>>/...
>> /site_perl
>>
>> All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
>> installing a newer patch-version by overwriting the existing one, the
>> structure looks like
>>
>> /usr
>> /lib
>>/perl5
>> /5.30.2
>>/...
>> /5.30.3
>>/...
>> /site_perl
>>
>> The 5.30.2-directory (which includes the modules) is more or less
>> garbage as the new perl will use 5.30.3. Therefore, any installed
>> module must be reinstalled to appear in the 5.30.3 structure.
>>
>> This all is not really a problem as long as the system is completely
>> built from scratch and all modules are installed freshly. For those
>> who uses some kind of pkgmnr or upgrade the system package by package
>> it might be a problem when perl is about to upgrade.
>>
>
> Yes, for my own systems I have had to rebuild all the modules if
> upgrading perl.
>
>> Suggestion:
>> The following is under the assumption that patch-versions of perl are
>> compatible to each other. To solve the upgrade issue described above,
>> add a few new options to the perl install command in the LFS book:
>>
>> sh Configure -des \
>>-Dprefix=/usr \
>>-
>> Dvendorprefix=/usr \
>> * -Dprivlib=/usr/share/perl5/core_perl
>> \
>> * -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \
>> * -
>> Dsitelib=/usr/share/perl5/site_perl \
>> * -
>> Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \
>> * -
>> Dvendorlib=/usr/share/perl5/vendor_perl \
>> * -
>> Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \
>>-
>> Dman1dir=/usr/share/man/man1 \
>>-Dman3dir=/usr/share/man/man3 \
>>-
>> Dpager="/usr/bin/less -isR" \
>>-Duseshrplib \
>>-
>> Dusethreads
>>
>> assuming that we have in packages.ent:
>>
>>
>>
>>
>>
>> > minor;.&perl-version-patch;">
>>
>> This will produce a directory structure:
>>
>> /usr
>> /lib
>>/perl5
>> /5.30
>>/core_perl
>> /...
>>/site_perl
>> /...
>>
>> where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
>> this case, overwriting the installed perl with a newer one has no
>> effect on the installed modules unless minor or even major version of
>> perl >
>
> Sounds nice. But just to be clear - under site_perl I have a
> versioned directory (e.g. 5.30.2 for your current example). I
> assume, or hope, that will either be 5.30 or completely omitted.
>
> i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or
> /usr/lib/perl5/5.30/site_perl/ for the directory where 'top level'
> modules SGMLS.pm and URI.pm live ?
>
>> A note to "make install" might be required as perl refuses to
>> overwrite an installation in case of an version mismatch (which makes
>> sense in case of incompatible version, maybe when minor or major
>> version changes). To overcome this, a
>>mv /usr/bin/perl{,.old}
>> can be executed before doing the install.
>>
>> As far as i have seen, there is no change required for BLFS except one
>> textual adjustment in the "Perl Modules" page.
>>
>> All comments, suggestions, tomatos and eggs are welcome!
>> Is there something i have completely overseen?
>>
>
> For plain perl modules in site_perl this sounds like a no-brainer.
> A quick look at .so files installed under x86_64-linux-thread-multi
> suggests that the site_perl files (e.g. from ImageMagick) do not
> link to perl libs, so should be ok, and the many core .so files seem
> (from a brief look at one or two) to only link to libc, vdso and
> ld-linux - in any case, the core files will be overwritten by the
> upgrade of perl.
>
> If a module is dropped from core perl, I suppose that will leave the
> old core module in place.
>
> Overall, I think it might be worth trying (I've had so much pain
> from perl over the years that I don't really believe there is such a
> thing as a free lunch, and my first semi-s
Re: [lfs-dev] perl install options
On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
> Hi all,
>
> this is about hte configuration options of perl.
>
> Problem:
> whenever perl is upgraded to a newer version (for example 5.30.2 to
> 5.30.3), all perl modules needs to be reinstalled as the current
> configuration of perl forces a directory structure like
>
> /usr
> /lib
> /perl5
> /5.30.2
> /...
> /site_perl
>
> All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
> installing a newer patch-version by overwriting the existing one, the
> structure looks like
>
> /usr
> /lib
> /perl5
> /5.30.2
> /...
> /5.30.3
> /...
> /site_perl
>
> The 5.30.2-directory (which includes the modules) is more or less
> garbage as the new perl will use 5.30.3. Therefore, any installed
> module must be reinstalled to appear in the 5.30.3 structure.
>
> This all is not really a problem as long as the system is completely
> built from scratch and all modules are installed freshly. For those
> who uses some kind of pkgmnr or upgrade the system package by package
> it might be a problem when perl is about to upgrade.
>
Yes, for my own systems I have had to rebuild all the modules if
upgrading perl.
> Suggestion:
> The following is under the assumption that patch-versions of perl are
> compatible to each other. To solve the upgrade issue described above,
> add a few new options to the perl install command in the LFS book:
>
> sh Configure -des \
> -Dprefix=/usr \
> -
> Dvendorprefix=/usr \
> * -Dprivlib=/usr/share/perl5/core_perl
> \
> * -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \
> * -
> Dsitelib=/usr/share/perl5/site_perl \
> * -
> Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \
> * -
> Dvendorlib=/usr/share/perl5/vendor_perl \
> * -
> Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \
> -
> Dman1dir=/usr/share/man/man1 \
> -Dman3dir=/usr/share/man/man3 \
> -
> Dpager="/usr/bin/less -isR" \
> -Duseshrplib \
> -
> Dusethreads
>
> assuming that we have in packages.ent:
>
>
>
>
>
> minor;.&perl-version-patch;">
>
> This will produce a directory structure:
>
> /usr
> /lib
> /perl5
> /5.30
> /core_perl
> /...
> /site_perl
> /...
>
> where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
> this case, overwriting the installed perl with a newer one has no
> effect on the installed modules unless minor or even major version of
> perl >
Sounds nice. But just to be clear - under site_perl I have a
versioned directory (e.g. 5.30.2 for your current example). I
assume, or hope, that will either be 5.30 or completely omitted.
i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or
/usr/lib/perl5/5.30/site_perl/ for the directory where 'top level'
modules SGMLS.pm and URI.pm live ?
> A note to "make install" might be required as perl refuses to
> overwrite an installation in case of an version mismatch (which makes
> sense in case of incompatible version, maybe when minor or major
> version changes). To overcome this, a
> mv /usr/bin/perl{,.old}
> can be executed before doing the install.
>
> As far as i have seen, there is no change required for BLFS except one
> textual adjustment in the "Perl Modules" page.
>
> All comments, suggestions, tomatos and eggs are welcome!
> Is there something i have completely overseen?
>
For plain perl modules in site_perl this sounds like a no-brainer.
A quick look at .so files installed under x86_64-linux-thread-multi
suggests that the site_perl files (e.g. from ImageMagick) do not
link to perl libs, so should be ok, and the many core .so files seem
(from a brief look at one or two) to only link to libc, vdso and
ld-linux - in any case, the core files will be overwritten by the
upgrade of perl.
If a module is dropped from core perl, I suppose that will leave the
old core module in place.
Overall, I think it might be worth trying (I've had so much pain
from perl over the years that I don't really believe there is such a
thing as a free lunch, and my first semi-supported version with this
would be LFS-10.0 so I won't actually find out for some months if
the approach lives up to expectations).
ĸen
--
He died at the console, of hunger and thirst.
Next day he was buried, face-down, nine-edge first.
- the perfect programmer
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] perl install options
Hi all,
this is about hte configuration options of perl.
Problem:
whenever perl is upgraded to a newer version (for example 5.30.2 to
5.30.3), all perl modules needs to be reinstalled as the current
configuration of perl forces a directory structure like
/usr
/lib
/perl5
/5.30.2
/...
/site_perl
All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
installing a newer patch-version by overwriting the existing one, the
structure looks like
/usr
/lib
/perl5
/5.30.2
/...
/5.30.3
/...
/site_perl
The 5.30.2-directory (which includes the modules) is more or less
garbage as the new perl will use 5.30.3. Therefore, any installed
module must be reinstalled to appear in the 5.30.3 structure.
This all is not really a problem as long as the system is completely
built from scratch and all modules are installed freshly. For those
who uses some kind of pkgmnr or upgrade the system package by package
it might be a problem when perl is about to upgrade.
Suggestion:
The following is under the assumption that patch-versions of perl are
compatible to each other. To solve the upgrade issue described above,
add a few new options to the perl install command in the LFS book:
sh Configure -des \
-Dprefix=/usr \
-
Dvendorprefix=/usr \
* -Dprivlib=/usr/share/perl5/core_perl
\
* -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \
* -
Dsitelib=/usr/share/perl5/site_perl \
* -
Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \
* -
Dvendorlib=/usr/share/perl5/vendor_perl \
* -
Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \
-
Dman1dir=/usr/share/man/man1 \
-Dman3dir=/usr/share/man/man3 \
-
Dpager="/usr/bin/less -isR" \
-Duseshrplib \
-
Dusethreads
assuming that we have in packages.ent:
This will produce a directory structure:
/usr
/lib
/perl5
/5.30
/core_perl
/...
/site_perl
/...
where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
this case, overwriting the installed perl with a newer one has no
effect on the installed modules unless minor or even major version of
perl changes.
A note to "make install" might be required as perl refuses to
overwrite an installation in case of an version mismatch (which makes
sense in case of incompatible version, maybe when minor or major
version changes). To overcome this, a
mv /usr/bin/perl{,.old}
can be executed before doing the install.
As far as i have seen, there is no change required for BLFS except one
textual adjustment in the "Perl Modules" page.
All comments, suggestions, tomatos and eggs are welcome!
Is there something i have completely overseen?
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] is "+h" really needed in chroot?
There was a paragraph in sect. 7.4 "Entering the Chroot Environment", reading:
> Notice that /tools/bin is not
> in the PATH. This means that a temporary tool will no longer be
> used once its final version is installed.
It does not make sense now as the final version will overwrite the temporary
tool in {/usr,}/{sbin,bin}, irrelevent to /tools/bin. So I modified it to:
> Notice that /tools/bin is not
> in the PATH. This means that the cross toolchain will no longer
> be used in the chroot environment. This occurs when the shell does not
> remember the locations of executed binaries—for this
> reason, hashing is switched off by passing the +h
> option.
But since the final version is simply overwriting the temporary tools *at the
same location*, I think it's not necessary to turn off bash hash in chroot.
Not tested yet.
--
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
