Re: [lfs-dev] Some comments on the test results.
On 2020-06-21 18:44 +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Jun 19, 2020 at 07:46:54PM +0100, Ken Moffat via lfs-dev wrote:
> > On Fri, Jun 19, 2020 at 06:58:42PM +0200, Pierre Labastie via lfs-dev wrote:
> > > On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > > > I've now been through my test logs for the new build (on my i7
> > > > haswell).
> > > >
> > > > Here are a few comments (in order of testing)
> > > >
>
> An update on ONLY my gcc test results.
>
> > > > gcc-10.1.0
> > > > --
> > > >
> > > > I seem to be getting rather more failures than the book implies,
> > > > although I don't think they are either serious or unexpected.
> > > >
> > > > First, 14 failures i nthe torture test, variants of
> > > > FAIL: gcc.c-torture/compile/limits-exprparen.c
> > >
> > > Isn't it the one that fails when ulimit is not increased?
> > >
> >
> > Maybe. I'm increasing the ulimit as root, then running the test as
> > 'tester', which matches the book. Again, my build of trunk from
> > 20200603 didn't fail these, but cross-chap5 from that date did.
> >
>
> Pierre later commented about CFLAGS. That turned out to be the
> cause of all the failures in the torture tests: with just -O3 in the
> CFLAGS and CXXFLAGS that batch of tests fail. With -O2 and
> optionally -march=native -fstack-clash-protection
> -fstack-protector-strong and (for CXX) -D_GLIBCXX_ASSERTION those
> tests pass.
>
> So, from now on I'm dropping back to -O2 for building gcc. I've
> uploaded a new Errata-2.txt to my tuning notes.
> > > > Second, as wel las the 6 locale/get_time test failures I also had
> > > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> > > > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> > >
> > > Never seen those ones
> > >
GCC itself is OK with -O3, but some tests are not. With "CFLAGS=-O3 ./configure
..." many tests will fail. The correct way is:
# some CFLAGS set up very early
export CFLAGS="-O3"
export CXXFLAGS="$CFLAGS"
# ... ... build other packages
{unset CFLAGS CXXFLAGS; ./configure ...}
make STAGE1_CFLAGS="-O3" BOOT_CFLAGS="-O3" CFLAGS_FOR_TARGET="-O3 -g"
-g is there because libstdc++ needs debug information.
But my make variables are for 3-stage bootstrapping. Not sure what should we do
with --disable-bootstrap.
> On my limited series of gcc-10 builds (one from trunk which turned
> out to not have any added CFLAGS because I'd borked the name of the
> file containing them, three builds of cross-chap5 and new trunk)
> the 20_util/unsynchronized_pool_resource/allocate.cc failure is not
> consistent.
>
> And on one build there was some other failure, whcih perhaps
> implies the testsuite is "variable".
>
> But 22_locale/numpunct/members/char/3.cc always fails for me.
>
> Looking at the test,
> libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
> it starts
>
> // { dg-require-namedlocale "nl_NL.ISO8859-15" }
>
> and a bit later it says
>
> // nl_NL chosen because it has no thousands separator (at this time).
> locale loc_it = locale(ISO_8859(15,nl_NL));
>
> (apparently it was originally using an italian locale, then changed)
>
> Now in theory I have all the locales on this system. My log from
> glibc for nl_NL shows:
>
> nl_NL.ISO-8859-1... done
> nl_NL.ISO-8859-15@euro... done
> nl_NL.UTF-8... done
>
> I have no idea how locales work in expect, but my normal quick test
> for a locale is to use 'LC_ALL=someting date' and there I find that
> only nl_NL and nl_NL.UTF-8 work, the rest give me english:
>
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
> Sat Jun 20 13:12:21 BST 2020
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-1 date
> Sat Jun 20 13:12:29 BST 2020
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15 date
> Sat Jun 20 13:13:35 BST 2020
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
> Sat Jun 20 13:13:41 BST 2020
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL.UTF-8 date
> za 20 jun 2020 13:13:53 BST
> ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL date
> za 20 jun 2020 13:14:40 BST
>
> Now, that seems to be the only nl_NL.ISO8859-15 test, but there are
> a lot which require de_DR.ISO8859-15, several for fr_FR.ISO8859-15
> and one for it_IT-ISO8859-15.
>
> I wondered if some of these might now fall into 'unsupported' (there
> doesn't seem to be any easy way of identifying what is in that), but
> my number of unsupported tests seems consistent at 344 in al lthe
> builds so I ended up clueless about why that test only fails for me.
> The test data seems to get deleted during the run, but the test is
> apparently comparing the result to an empty string, so probably a
> thousands separator was returned.
>
> Interestingly, wikipedia suggests that the Netherlands uses a dot
> '.' as the separator https://en.wikipedia.org/wiki/Decimal_separator
> (in Examples of use, the entry for
Re: [lfs-dev] Some comments on the test results.
On Fri, Jun 19, 2020 at 07:46:54PM +0100, Ken Moffat via lfs-dev wrote:
> On Fri, Jun 19, 2020 at 06:58:42PM +0200, Pierre Labastie via lfs-dev wrote:
> > On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> > > I've now been through my test logs for the new build (on my i7
> > > haswell).
> > >
> > > Here are a few comments (in order of testing)
> > >
An update on ONLY my gcc test results.
> > >
> > > gcc-10.1.0
> > > --
> > >
> > > I seem to be getting rather more failures than the book implies,
> > > although I don't think they are either serious or unexpected.
> > >
> > > First, 14 failures i nthe torture test, variants of
> > > FAIL: gcc.c-torture/compile/limits-exprparen.c
> >
> > Isn't it the one that fails when ulimit is not increased?
> >
>
> Maybe. I'm increasing the ulimit as root, then running the test as
> 'tester', which matches the book. Again, my build of trunk from
> 20200603 didn't fail these, but cross-chap5 from that date did.
>
Pierre later commented about CFLAGS. That turned out to be the
cause of all the failures in the torture tests: with just -O3 in the
CFLAGS and CXXFLAGS that batch of tests fail. With -O2 and
optionally -march=native -fstack-clash-protection
-fstack-protector-strong and (for CXX) -D_GLIBCXX_ASSERTION those
tests pass.
So, from now on I'm dropping back to -O2 for building gcc. I've
uploaded a new Errata-2.txt to my tuning notes.
> > >
> > > Second, as wel las the 6 locale/get_time test failures I also had
> > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> > > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> >
> > Never seen those ones
> >
On my limited series of gcc-10 builds (one from trunk which turned
out to not have any added CFLAGS because I'd borked the name of the
file containing them, three builds of cross-chap5 and new trunk)
the 20_util/unsynchronized_pool_resource/allocate.cc failure is not
consistent.
And on one build there was some other failure, whcih perhaps
implies the testsuite is "variable".
But 22_locale/numpunct/members/char/3.cc always fails for me.
Looking at the test,
libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
it starts
// { dg-require-namedlocale "nl_NL.ISO8859-15" }
and a bit later it says
// nl_NL chosen because it has no thousands separator (at this time).
locale loc_it = locale(ISO_8859(15,nl_NL));
(apparently it was originally using an italian locale, then changed)
Now in theory I have all the locales on this system. My log from
glibc for nl_NL shows:
nl_NL.ISO-8859-1... done
nl_NL.ISO-8859-15@euro... done
nl_NL.UTF-8... done
I have no idea how locales work in expect, but my normal quick test
for a locale is to use 'LC_ALL=someting date' and there I find that
only nl_NL and nl_NL.UTF-8 work, the rest give me english:
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:12:21 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-1 date
Sat Jun 20 13:12:29 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15 date
Sat Jun 20 13:13:35 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL-8859-15@euro date
Sat Jun 20 13:13:41 BST 2020
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL.UTF-8 date
za 20 jun 2020 13:13:53 BST
ken@plexi /scratch/ken/tests/gcc-10.1.0 $LC_ALL=nl_NL date
za 20 jun 2020 13:14:40 BST
Now, that seems to be the only nl_NL.ISO8859-15 test, but there are
a lot which require de_DR.ISO8859-15, several for fr_FR.ISO8859-15
and one for it_IT-ISO8859-15.
I wondered if some of these might now fall into 'unsupported' (there
doesn't seem to be any easy way of identifying what is in that), but
my number of unsupported tests seems consistent at 344 in al lthe
builds so I ended up clueless about why that test only fails for me.
The test data seems to get deleted during the run, but the test is
apparently comparing the result to an empty string, so probably a
thousands separator was returned.
Interestingly, wikipedia suggests that the Netherlands uses a dot
'.' as the separator https://en.wikipedia.org/wiki/Decimal_separator
(in Examples of use, the entry for 1.234.567,89) and
https://www.freeformatter.com/netherlands-standards-code-snippets.html#numericformats
agrees that the grouping character is the dot. on that basis I
expect this test to fail for everyone!
if the test is to pass, I guess (from wikipedia) that de_DE might
work - but since it apparently doesn't fail for everyone I might
again be barking up completely the wrong tree.
ĸ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] incorrect note about libstdc++ in toolchain technical notes?
On 2020-06-21 14:24 +0200，Pierre Labastie via lfs-dev wrote: > On Sun, 2020-06-21 at 14:18 +0800, Xi Ruoyao via lfs-dev wrote: > > 在 2020-06-21星期日的 14:14 +0800，Xi Ruoyao via lfs-dev写道： > > > > "As said above, the standard C++ library is compiled next, > > > > followed in > > > " > > > > "linkend=\"chapter-temporary-tools\"/> by all the programs that > > > > need " > > > > "themselves to be built. The install step of all those packages > > > > uses the " > > > > "DESTDIR variable to have the programs land into > > > > the LFS " > > > > "filesystem." > > > > > > "Followed in chapter-temporary-tools" means libstdc++ pass 2, but > > > in pass 2 > > > DESTDIR is not installed. IMO it should be chapter-cross-tools and > > > this > > > libstdc++ means pass 1. > > > > s/installed/used/ > > > > I can't type :(. > > -- > > Xi Ruoyao > > School of Aerospace Science and Technology, Xidian University > > > > Well, the chapter following the first install of libstdc++ is chapter- > temporary-tools (numbered 6 presently). Maybe it is not clear, but what > is meant is: > After the (first) build of libstdc++ comes the installation of all the > programs in chapter 6, and this (first) build of libstdc++ as well as > the build of those programs use DESTDIR (actually also glibc, but this > should maybe be said above). Oh I understand. I couldn't read English :(. -- 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 07:29 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/21/20 5:33 AM, Xi Ruoyao via lfs-dev wrote: > > On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote: > > > On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: > > > > On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: > > > > > 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 serio
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/21/20 5:33 AM, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote: On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: 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 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 work on Arch in Nov 2019). Which distro are you using? I tried Arch (latest) and Ubuntu (18.04) on my laptops, and SUSE (leap 15.2) on distrotest.net. On all of these --norc works so maybe we can throw every environment variables into env command in .bash_profile and use --norc. I was using the system installed by ubuntu-20.04-desktop-amd64.iso for testing. If you do 'env -i bash --norc' and then 'set', do you get all the bash completion macros? No. I trie
Re: [lfs-dev] incorrect note about libstdc++ in toolchain technical notes?
On Sun, 2020-06-21 at 14:18 +0800, Xi Ruoyao via lfs-dev wrote: > 在 2020-06-21星期日的 14:14 +0800，Xi Ruoyao via lfs-dev写道： > > > "As said above, the standard C++ library is compiled next, > > > followed in > > " > > > "linkend=\"chapter-temporary-tools\"/> by all the programs that > > > need " > > > "themselves to be built. The install step of all those packages > > > uses the " > > > "DESTDIR variable to have the programs land into > > > the LFS " > > > "filesystem." > > > > "Followed in chapter-temporary-tools" means libstdc++ pass 2, but > > in pass 2 > > DESTDIR is not installed. IMO it should be chapter-cross-tools and > > this > > libstdc++ means pass 1. > > s/installed/used/ > > I can't type :(. > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University > Well, the chapter following the first install of libstdc++ is chapter- temporary-tools (numbered 6 presently). Maybe it is not clear, but what is meant is: After the (first) build of libstdc++ comes the installation of all the programs in chapter 6, and this (first) build of libstdc++ as well as the build of those programs use DESTDIR (actually also glibc, but this should maybe be said above). Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote: > On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: > > On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: > > > 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
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: > > 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 op
Re: [lfs-dev] proposal: prevent the influence of host /etc/bash.bashrc
On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: 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 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 work on Arch in Nov 2019). Which distro are you using? I tried Arch (latest) and Ubuntu (18.04) on my laptops, and SUSE (leap 15.2) on distrotest.net. On all of these --norc works so maybe we can throw every environment variables into env command in .bash_profile and use --norc. I was using the system installed by ubuntu-20.04-desktop-amd64.iso for testing. If you do 'env -i bash --norc' and then 'set', do you get all the bash completion macros? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
