Re: [lfs-dev] Systemd-247 stops with warnings
On 2021-04-15 22:28 +0800, Xi Ruoyao wrote: > > It's caused by changes in Linux 5.11.14 (API headers). I'll raise a PR in > systemd. It's already fixed in systemd git repo. > The kernel version in the book (5.11.10) won't trigger this. -- 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] Systemd-247 stops with warnings
On 2021-04-15 14:01 +0100, John Burrell via lfs-dev wrote:
> Using the systemd development version of the book 20210326-systemd,
> when compiling I get:
>
> FAILED: systemd-rfkill.p/src_rfkill_rfkill.c.o
>
> and then:
>
> ../src/rfkill/rfkill.c:339:23: warning: comparison of integer
> expressions of different signedness: ‘ssize_t’ {aka ‘long int’} and
> ‘long unsigned int’ [-Wsign-compare]
> 339 | if (l < RFKILL_EVENT_SIZE_V1)
> | ^
> In file included from ../src/basic/macro.h:657,
> from ../src/basic/alloc-util.h:9,
> from ../src/rfkill/rfkill.c:13:
> ../src/rfkill/rfkill.c:340:70: error: format ‘%d’ expects argument of
> type ‘int’, but argument 8 has type ‘long unsigned int’
> [-Werror=format=]
> 340 | return
> log_error_errno(SYNTHETIC_ERRNO(EIO), "Short read of struct
> rfkill_event: (%zd < %d)",
>
> and finally:
>
> cc1: some warnings being treated as errors
> [791/1466] Compiling C object
> src/resolve/libsystemd-resolve-core.a.p/resolved-dns-packet.c.o
> ninja: build stopped: subcommand failed.
>
> Out of interest, I tried version 248 but that produced the same result.
It's caused by changes in Linux 5.11.14 (API headers). I'll raise a PR in
systemd.
The kernel version in the book (5.11.10) won't trigger this.
--
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] Final call for changes before LFS/BLFS 10.1 release
On 2021-02-26 22:31 -0600, Bruce Dubbs via lfs-dev wrote: > On 2/26/21 10:13 PM, Xi Ruoyao via lfs-dev wrote: > > On 2021-02-26 21:26 -0600, Bruce Dubbs via lfs-dev wrote: > > > We are about ready to release LFS/BLFS 10.1. All tickets have been > > > closed and all packages have been tested using the current instructions > > > in the books. > > > > > > That said, there are probably issues that still need to be addressed. > > > If LFS is printed out on paper, it is about 300 pages. If BLFS is > > > printed out paper, it is over 2000 pages. This is the last call for > > > change proposals before the books are released on Monday, March 1st. > > > > > > All proposals will be considered, but major changes probably will need > > > to be delayed until the next cycle. However, minor changes can be done > > > now. > > > In section 11.3 (rebooting), it it better to replace those umount commands > > with > > a simple "umount -R $LFS"? > > That's a good idea. When I set up chroot, I do a little more than what > in the book for work in chroot after LFS is completed: > > ├─/usr/src lfs91:/srv/src nfs > ├─/mnt/lfs /dev/nvme0n1p8 ext4 > │ ├─/mnt/lfs/dev devtmpfs devtmpfs > │ │ └─/mnt/lfs/dev/pts devpts devpts > │ ├─/mnt/lfs/proc proc proc > │ ├─/mnt/lfs/sys sysfs sysfs > │ ├─/mnt/lfs/run run tmpfs > │ ├─/mnt/lfs/usr/src lfs91:/srv/src nfs > │ ├─/mnt/lfs/boot /dev/nvme0n1p2 ext2 > │ └─/mnt/lfs/home /dev/nvme0n1p5 ext4 > > When I do # umount -Rv $LFS, I get: > > umount: /mnt/lfs/dev/pts unmounted > umount: /mnt/lfs/dev unmounted > umount: /mnt/lfs/proc unmounted > umount: /mnt/lfs/sys unmounted > umount: /mnt/lfs/run unmounted > Legacy NFS mount point detected > lfs91:/srv/src umounted > umount: /mnt/lfs/boot unmounted > umount: /mnt/lfs/home unmounted > umount: /mnt/lfs unmounted > > Which does seem to do the right thing. In spite of the message about > NFS, it only umounts /mnt/lfs/usr/src and not /usr/src. > > -- Bruce Commited at r12146. -- 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] Final call for changes before LFS/BLFS 10.1 release
On 2021-02-26 21:26 -0600, Bruce Dubbs via lfs-dev wrote: > We are about ready to release LFS/BLFS 10.1. All tickets have been > closed and all packages have been tested using the current instructions > in the books. > > That said, there are probably issues that still need to be addressed. > If LFS is printed out on paper, it is about 300 pages. If BLFS is > printed out paper, it is over 2000 pages. This is the last call for > change proposals before the books are released on Monday, March 1st. > > All proposals will be considered, but major changes probably will need > to be delayed until the next cycle. However, minor changes can be done > now. > > -- Bruce In section 11.3 (rebooting), it it better to replace those umount commands with a simple "umount -R $LFS"? -- 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] Util-linux uuidd.service file specifies a user and group
On 2021-01-27 15:22 -0600, Brendan L via lfs-dev wrote: > For the systemd book util-linux installs uuidd.service and > uuidd.socket. The service file specifies a user and group of uuidd. > Should that user and group be added to the book? Added in r12103. Thanks for report. -- 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] SV 2021-01-01
On 2021-01-01 11:20 +, Roger via lfs-dev wrote: > Chapter 8.16.1 installation of bc. > > CFLAGS is included in the explanation of the configuration > options but they have been removed. > -- > Roger > Fixed at r12079. Thanks for the report. I shouldn't do the changes when I was sleepy :(. -- 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] IANA-ETC protocols/services file problems
On 2020-11-14 07:38 -0800, Joel Bion via lfs-dev wrote: > I also am using the tagged-as-a-release 20201110 > > It turns out that this is the difference: if you grab the tar file from > the line that says "source code (tar.gz)" you get a package without the > services/protocols files, and the need to run update.py. If you grab the > tar file from the line that says iana-etc-20201110.tar.gz - then you get > the pre-built protocols and services file. > > Are these files typically DIFFERENT? I've not seen that before. Yes they are typically different. "source code (tar.gz)" is automatically created by GitHub so there will be no generated files (which should not be version controled) in it. -- 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] Formatting of Package download URIs
On 2020-11-11 09:53 -0600, Bruce Dubbs via lfs-dev wrote: > On 11/11/20 3:21 AM, Kevin Buckley via lfs-dev wrote: > > I was recently trying to generate a downlaod listing of the packages I had > > used > > when building my Pkguser based 9.1 system, inclduing the BLFS components > > that I'd merged into a single book. > > > > FWIW, so as to see what I needed to download from BLFS 10.0 > > > > I noticed that in BLFS, where the package download URIs are presented within > > the > > packages section, one ends up with entries akin to (links/lynx dump output) > > > > * Download (HTTP): https://www.domain.tld/path/to/taball.tar.xz > > * Download (FTP): ftp://ftp.domain.tld/path/to/taball.tar.xz > > > > however, in the LFS Book, where all of the package tarball URIs are listed > > in > > the one section, it's just > > > > * Download: https://www.domain.tld/path/to/taball.tar.xz > > > > or, for the odd package, > > > > * Download: ftp://ftp.domain.tld/path/to/taball.tar.xz > > > > I'm aware that there is no reason the LFS and BLS books should exhibit any > > consistency, but was wondering if having the LFS Book "adopt" the BLFS > > markup might be doable, or rather, if there was anything in way that the > > package download listing is generated that might prevent it being done? > > The design of LFS is that all the packages are expected to be built. In > BLFS, the user chooses what packages to build. > > Another issue with LFS is that there are packages only built in the > chroot environment. Downloading a package in chroot is not really > practical. > > Also I'll note that users of the stable book can download everything > with a single wget command in Chapter 3.1 or one tarball from > ftp://ftp.osuosl.org/pub/lfs/lfs-packages/ or its mirrors. Adding a link in package page will make it easier when some LFS package need to be upgraded in a completed system. -- 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] Installing in /lfs instead of /lfs/tools in chapter 6
On 2020-09-12 13:48 +0200, Tim Tassonis via lfs-dev wrote: > Hi all > > I'm finally doing a full new build of LFS (Version 10.0) and have > noticed that in chapter 6, the temporary tools are now installed > directly into $LFS, unlike in older versions, where they went into > $LFS/tools. > > I assume this has some advantages, but I liked the old approach, as it > gave me a clean $LFS before chapter 8. > > In my case, I used a package manager from chapter 8 on, and my package > would npw be complaining about overwriting unknown files a lot. > > I can add an option abouit forcing to overwrite files, but I wondered if > installind chapter 6 into $LFS/tools is still supported somehow? No. If you do that you'll risk to have some hardcoded paths to /tools, in some executables and scripts of your final system. The most significant advantage of the new approach is that we won't need to track and develop workaround for those faulty paths anymore. -- 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] host /usr/share/config.site may break build
On 2020-09-04 09:30 +0200，Pierre Labastie via lfs-dev wrote:
> On Fri, 2020-09-04 at 00:47 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 9/3/20 10:53 PM, Xi Ruoyao via lfs-dev wrote:
> > > Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary
> > > Tools". The
> > > problem is that configure scripts (generated by autoconf) will try
> > > to load
> > > ${prefix}/share/config.site and ${prefix}/etc/config.site. These
> > > things are
> > > really "powerful" - they can even override some command line
> > > options.
> > >
> > > "/usr/etc" should not exist on any FHS-compilant distro, but
> > > "/usr/share/config.site" exists on many distros.
> > >
> > > My suggestion is to add `export CONFIG_SITE=/dev/null` in
> > > /home/lfs/.bashrc. It
> > > would override the default config.site search rule.
> >
> > I don't know that we have ${prefix}/etc/config.site. I do not. I
> > do
> > have /usr/etc/xdg/autostart/xfce4-notifyd.desktop that was installed
> > yesterday when I updated xfce4-notifyd.
> >
> > We probably need to specify --sysconfdir=/etc for that.
> >
>
> As an example, fedora has /usr/share/config.site in the autoconf
> package. This one is smart and is skipped in case of cross compilation,
> but just in case, I second Xi Ruoyao's proposal. Or even to have
>
> CONFIG_SITE=$LFS/usr/share/config.site
>
> We might then create a config.site for our own use, for example with
> prefix=/usr
> sysconfdir=/etc
> localestatedir=/var
> sharedstatedir=/var
>
> That would prevent the need to have those in the configure commands...
>
> Pierre
No, that will cause some unexpected behavior.
To fix some typical non-FHS directories we should explicitly check them, like:
if [ sysconfdir = "/usr/etc" ]; then
sysconfdir=/etc
fi
--
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] host /usr/share/config.site may break build
Now we are using --prefix=/usr in "Ch. 6 Cross Compiling Temporary Tools". The
problem is that configure scripts (generated by autoconf) will try to load
${prefix}/share/config.site and ${prefix}/etc/config.site. These things are
really "powerful" - they can even override some command line options.
"/usr/etc" should not exist on any FHS-compilant distro, but
"/usr/share/config.site" exists on many distros.
My suggestion is to add `export CONFIG_SITE=/dev/null` in /home/lfs/.bashrc. It
would override the default config.site search rule.
--
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] User and group tester
On 2020-09-03 12:18 +0100, Roger via lfs-dev wrote: > LFS-10.0 At the end of chapter 8 user tester is deleted. > Shouldn't group tester also be deleted? It's deleted by userdel. See the description of `USERGROUPS_ENAB` in /etc/login.defs. -- 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] Comments on the expected test results in the book
On 2020-08-21 17:59 -0500, Bruce Dubbs via lfs-dev wrote: > On 8/21/20 4:40 PM, Ken Moffat via lfs-dev wrote: > > I've now run the full set of tests on three different builds of > > 10.1-rc1, and I'm almost in agreement about the expected results. > > > > Two builds were on ryzen. Those used -O3 throughout, even in gcc > > where I had stopped doing that because of failures I described as in > > the torture tests. Reinstated because on a semi-decent development > > machine I want to build more quickly. The other build was one my i3 > > skylake using -O2 - it's not a main development machine. > > > > The following packages still cause me to query what the book says: > > > > tcl: I still think that the line > > Files with failing tests: http.test httpold.test > > should be mentioned in addition to the clock test (which exits with > > errors). > > > > gcc: I get two additional failures in libstdc++ on all three > > machines, > > > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test > > FAIL: 22_locale/numpunct/members/char/3.cc execution test I didn't see them. Neither Bruce's build log. > > Totals for unexpected failures in my builds: > > -O2 -O3 > > g++ 1717 and 18 > > gcc 721 > > libstdc++ 8 8 > > > > So, using -O3 still breaks some more gcc torture tests (but the > > build seems to work well). But I think those two extra libstdc++ > > failures ought to be mentoned. > > > > Python: for me, test_normalization passed on each build. Not sure > > if it still fails for you guys ? It fails trying to download some test file from Internet. I guess it passed on your PC because your host has nscd running and it cached the IP of www.pythontest.net, then /etc/resolv.conf is not used. I disabled nscd because it's causing problems in my network environment. And should we put `make test` into a ? Then jhalfs would run it. Currently we have an empty log like http://www.linuxfromscratch.org/lfs/build-logs/10.0-rc1/AMD3900X/test-logs/847-Python-3.8.5 . > > coreutils: We say test-getlogin is known to fail, but in each of my > > builds I have: > > SKIP: test-getlogin It still fails on my build. > > util-linux: we pass -k to make check without specifying any details. > > For me, column/invalid multibyte failed on each of my builds. I didn't see the failure. > > Apart from these minor details of what to expect, this is now all > > looking really good. I'll also mention that for inetutils, where > > libls _may_ fail, it failed on the O2 build and one of the O3 > > builds, but not on the other O3 build. > > We are still working on tags fo rBLFS, so I opened a ticket on LFS so we > don't forget. > > http://wiki.linuxfromscratch.org/lfs/ticket/4720 > >-- Bruce > -- 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] Typos
On 2020-08-19 23:10 +0800，Xi Ruoyao via lfs-dev: > On 2020-08-19 10:25 -0400, Julien Lepiller via lfs-dev wrote: > > In chapter 3, I found "optain" instead of obtain. In chapter 4 there are at > > least two "envirnment", missing a o. I tried to fix it myself as I think I > > have access to the svn, but got a permission denied to write something in > > /srv/svn. > > I can see only one "envirnment". The others are "envronment" etc. > I'll try to create something like a enchant dictionary for LFS. Fixed "optain", "envirnment", along with several other typos found by enchant at r12029. -- 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] Typos
On 2020-08-19 10:25 -0400, Julien Lepiller via lfs-dev wrote: > In chapter 3, I found "optain" instead of obtain. In chapter 4 there are at > least two "envirnment", missing a o. I tried to fix it myself as I think I > have access to the svn, but got a permission denied to write something in > /srv/svn. I can see only one "envirnment". I'll try to create something like a enchant dictionary for LFS. -- 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] Bash patches
On 2020-08-19 13:38 +0100, Roger via lfs-dev wrote: > The current bash patches file only includes the first 11 > patches. There have been a further 7 issued this year. > > Is Pierre in a position to issue an updated patches file? Editors have tagged a lot of BLFS packages. If there is no security issue it's better to update the patches in 10.1. But if there is some security issue we'll have to do it now, release LFS-10.0-rc2, and redo all BLFS packages. -- 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] SVN 2020-08-18 chpater 7.11 Python
On 2020-08-19 13:55 +0100, Roger via lfs-dev wrote: > The "make install" of python in chapter 7 doesn't complete; my > scripts finished rather abruptly at this point. Has this been > noticed by anybody else? > > The problem is zlib is missing. I decided to change chapter 7 > to include zlib. I now do: > > 7.7 libstdc++ > zlib > 7.8 gettext It shouldn't happen. Python building system will skip to build zlib module if zlib is not found. Quote from Bruce's log: http://www.linuxfromscratch.org/lfs/build-logs/10.0-rc1/AMD3900X/logs/709-Python-3.8.5 > Python build finished successfully! > The necessary bits to build these optional modules were not found: > _bz2 _dbm _gdbm > _hashlib _sqlite3 _ssl > _tkinter _uuid nis > readline zlib > To find the necessary bits, look in setup.py in detect_modules() for the > module's name. Chapter 7 is temporary so we don't care about those extra modules. -- 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] Version 20200806-systemd
>| ^ > ../src/network/netdev/fou-tunnel.c:161:9: note: in expansion of macro > ‘assert_cc’ >161 | assert_cc(IPPROTO_MAX-1 <= UINT8_MAX); >| ^ > [530/1741] Compiling C object > src/network/libnetworkd-core.a.p/netdev_macsec.c.o > ninja: build stopped: subcommand failed. Perhaps the recent change just broke systemd-245. I used systemd-246 in my build and there was no problem. -- 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 privlib is putting core modules in /usr/share
On 2020-08-05 22:03 +0100, Ken Moffat via lfs-dev wrote:
> On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> > > (I've changed the subject and cut down some of hte obsolete detail)
> > >
> > > On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote:
> [...]
> > > False-ish alarm : the "missing" modules were installed in the
> > > initial (chapter 7) build, but they are in
> > > /usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl.
> > >
> > > The items in /usr/lib/perl5/5.32/core_perl were either installed by
> > > chapter 7 perl, as someone mentioned the other day, or (a few) were
> > > installed in chapter 8 perl. But all the items in /usr/share are
> > > from chapter 7 and ;acking the 5.32 version.
> > >
> > > At best, the location of the modules looks messy and I'm not happy
> > > that they are in unversioned directories.
> > >
> > > These are from the privlib.
> > >
> > > The first useful match for privlib which I found was a bug from a
> > > module developer (5.30 was doing somethign different from 5.26)
> > > where the output from cpan mentioned privlib:
> > > Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0
> > >
> > > https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html
> > >
> > > (Just pasting the link in case it is of any interest later)
> > >
> > > I think that
> > >
> > > https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl
> > >
> > > provides detailed explanations, and that from the UPDATE there we
> > > should at least be using a version in the privlib i.e.
> > > /usr/share/perl5/5.32/core_perl.
> > >
> > > But until now we have managed without putting pure perl core modules
> > > in /usr/share (although ISTR that when we used separate modules
> > > related to git - perhaps Errno.pm - something did go into
> > > /usr/share.
> > >
> > > We did not used to have -Dprivlib, I guess that dropping that would
> > > stop core modules being placed in /usr/share.
> > >
> > > This leaves the items in /usr/lib/perl5/core_perl which were NOT
> > > updated in chapter 8. Looking at the times in ls -lR these are
> > > either pure perl modules (*.pm), headers (in CORE) or else
> > > directories. I'm happy that those have not been changed between
> > > chapter 7 and chapter 8.
> > >
> > > I'll start a build WITHOUT Dprivlib later.
> >
> > Is there any rationale to change the default Perl module directory, besides
> > to
> > remove the Perl patch level from path?
> >
>
> Som of the modules (.so libs) are in archlib, i.e.
> /usr/lib/perl5/5.32/core_perl
>
> > I suggest three alternatives:
> >
> > (1) -Dprivlib=/usr/share/perl5/5.32/core_perl
> >
> > It's like the status quo, but versioned.
> >
>
> I am hopeful that not specifying privlib will do that. If not, I
> will go with that.
It's not. The default is /usr/lib/perl5/5.32.0.
> > (2) -Dprivlib=/usr/lib/perl5/5.32
> >
> > It's almost the default, but patch level (".0") removed. -Darchlib will
> > also
> > need to be adjusted.
> >
> I don't understand how you would change archlib ? At the moment it
> is /usr/lib/perl5/5.32/core_perl unless you mean to remove core_perl
> which was one of the features of Thomas's original proposal for the new
> layout :
> http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-June/073877.html
>
> The possibility that anything other than vendor modules (i.e. from
> third parties) would end up in /usr/share was not apparent.
>
> > (3) -Dprivlib=/usr/lib/perl5/5.32/core_perl
> >
> > It matches the current -Darchlib.
> >
>
> Another possibility.
>
> > And, -Dvendorlib should also be adjusted in the same manner.
>
> I suppose that setting vendorlib the same as vendorarch, i.e.
> /usr/lib/perl5/5.32/vendor_perl would make sense, but I don't have
> anything (third-party?) that installs in vendor_lib.
I prefer to put everything into /usr/lib/perl5, instead of using
/usr/share/perl5. Like:
sh Configure -des \
-Dprefix=/usr\
-Dvendorprefix=/usr \
-Dprivlib=/usr/lib/perl5/
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote:
> (I've changed the subject and cut down some of hte obsolete detail)
>
> On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote:
> > O Wed, Aug 05, 2020 at 01:54:44AM +0100, Ken Moffat via lfs-dev wrote:
> > > I'm looking at perl module dependencies, and I can see a reference
> > > to Test::More in a test, although I'm not sure if that test actually
> > > gets run. The reason I'm askng is that this used to be a core
> > > module, but I cannot see it in my 5.32.0 builds, althought the man
> > > page for Test::More.3 is still installed.
> > >
> > > Looking at https://perldoc.perl.org/Test/More.html suggests it is
> > > still part of core perl.
> > >
> > > Does anyone have any knowledge of this, please ?
> > >
> > > ĸen
> [...]
> > It occurred to me that I could go to my backups and look at the
> > files from the last old-style build I did. That was for 5.30.3, so
> > I expect some slight variation.
> >
> > What I did in each of the core perl root directories was run
> > find . -name '*.pm' | sort >somefile
> >
> > I'm attaching these (new-style-5.32.0 first), on the face of it I
> > seem to have lost a phenomenal amount of modules. But so far all my
> > perl module builds and tests have worked, so I hope I'm missing
> > something obvious.
> >
>
> False-ish alarm : the "missing" modules were installed in the
> initial (chapter 7) build, but they are in
> /usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl.
>
> The items in /usr/lib/perl5/5.32/core_perl were either installed by
> chapter 7 perl, as someone mentioned the other day, or (a few) were
> installed in chapter 8 perl. But all the items in /usr/share are
> from chapter 7 and ;acking the 5.32 version.
>
> At best, the location of the modules looks messy and I'm not happy
> that they are in unversioned directories.
>
> These are from the privlib.
>
> The first useful match for privlib which I found was a bug from a
> module developer (5.30 was doing somethign different from 5.26)
> where the output from cpan mentioned privlib:
> Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0
>
> https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html
>
> (Just pasting the link in case it is of any interest later)
>
> I think that
>
> https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl
>
> provides detailed explanations, and that from the UPDATE there we
> should at least be using a version in the privlib i.e.
> /usr/share/perl5/5.32/core_perl.
>
> But until now we have managed without putting pure perl core modules
> in /usr/share (although ISTR that when we used separate modules
> related to git - perhaps Errno.pm - something did go into
> /usr/share.
>
> We did not used to have -Dprivlib, I guess that dropping that would
> stop core modules being placed in /usr/share.
>
> This leaves the items in /usr/lib/perl5/core_perl which were NOT
> updated in chapter 8. Looking at the times in ls -lR these are
> either pure perl modules (*.pm), headers (in CORE) or else
> directories. I'm happy that those have not been changed between
> chapter 7 and chapter 8.
>
> I'll start a build WITHOUT Dprivlib later.
Is there any rationale to change the default Perl module directory, besides to
remove the Perl patch level from path?
I suggest three alternatives:
(1) -Dprivlib=/usr/share/perl5/5.32/core_perl
It's like the status quo, but versioned.
(2) -Dprivlib=/usr/lib/perl5/5.32
It's almost the default, but patch level (".0") removed. -Darchlib will also
need to be adjusted.
(3) -Dprivlib=/usr/lib/perl5/5.32/core_perl
It matches the current -Darchlib.
And, -Dvendorlib should also be adjusted in the same manner.
--
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] grub with uefi for LFS 10?
On 2020-08-05 14:37 +0800, Kevin Buckley via lfs-dev wrote: > On Mon, 3 Aug 2020 at 00:46, Xi Ruoyao via lfs-dev > wrote: > > It's nearly impossible. If we do that we'll have to introduce at least five > > new > > packages: dosfstools, popt, pciutils, efivar, and efibootmgr. Pciutils is > > recommended to be installed along with "which" (it's a package's name), and > > one > > of wget/curl/lynx to make update-pciids script usable. And, to make grub > > menu > > "showing normal" we'll need freetype. Freetype has a circular dependency > > with > > harfbuzz. Harfbuzz requires glib, graphite, and ICU to be fully functional. > > > > Worth pointing out, as the hint does, that you can install Freetype > without the harfbuzz, so as to get enough to install an enhanced > Grub, and then go back and install a Freetype+harfbuzz later. That's my approach, and OK for a hint. Another way: provide a binary unicode.pf2 file on Anduin, and skip freetype. It's just a font and it's not a problem not to build a font "from scratch". > Similarly, the lack of an update-pciids script may not be a major > problem as, when building the UEFI-aware Grub for the first time, > you can download what that script would fetch, using the host > system, and just put the payload into place on the LFS system. The problem is we have to defer the activation of update-usbids.timer (for systemd) or cron job (for sysv) after wget/curl/lynx is installed. Then where should we put the instruction? Not a technical problem but a book structure issue. > It's probably way too far beyond LFS to have it in the LFS Book, > but the basic capabilities are not as hard to add as one might > come to think, just by following all of the BLFS Book's dependencies > to the end of each chain. I think it might be better to put EFI grub and its dependencies into BLFS. There is BLFS #5379 (opened 6 years ago). If Bruce agrees I'll change the milestone to 10.1 (10.0 will be too hurry) and do it. And, William Harrington suggested that LFS should support some non-x86 architectures, which would require different bootloaders. They can be put into a new BLFS chapter "alternative bootloaders", along with EFI grub. -- 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] grub with uefi for LFS 10?
On 2020-08-05 14:26 +0800, Kevin Buckley via lfs-dev wrote: > On Sun, 2 Aug 2020 at 04:32, Timothy Russo via lfs-dev > wrote: > > With efi being more the standard now, I'd like to ask if we could default > > grub to supporting uefi instead of having to use the uefi hint. > > > > Or at last maybe formalize it and make it an option, where you can pick > > bios/mbr or uefi option. > > > > As the last person to update that hint (and, yes, it's in need of more > updating > for newer package versions!), then you must have seen that there are extra > packages, beyond those in the LFS core, that are needed to "enhance" Grub. > > Note also, that as you are probably building LFS on a system that may have > a UEFI-aware bootloader, you don't necessarily need a bootloader provided > by LFS. > > Maybe a UEFI-aware Grub could be part of BLFS though? [Cross post to blfs-dev] I personally agree. Let's hear Bruce's opinion. If he agree I'll do it for BLFS 10.1, and reference it in LFS 10.1. 10.0 is too hurry, I think. For 10.0 I'll update the hint again. -- 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] grub with uefi for LFS 10?
On 2020-08-02 22:19 +0100, Ken Moffat via lfs-dev wrote: > On Sun, Aug 02, 2020 at 10:07:23PM +0200, Alexey Orishko via lfs-dev wrote: > > On Sun, Aug 2, 2020 at 6:46 PM Xi Ruoyao via lfs-dev > > wrote: > > > > > > Since majority of new laptops have EFI, it would really help to have > > > The readers who don't need EFI will be annoyed. meson/ninja already > > > annoyed > > > the readers using sysvinit. > > > > Quote from Linux From Scratch - Version SVN-20200721 / Preface / vi. > > Rationale for Packages in the Book: > > "As stated earlier, the goal of LFS is to build a complete and usable > > foundation-level system. ..." > > If LFS cannot be booted on modern pc, the statement above should be > > changed to "... usable foundation-level system on LEGACY computers > > only." > > Otherwise information in preface creates a false assurance that > > building LFS is enough to boot and continue with BLFS on some modern > > target system. > > > > /alexey LFS is usable on modern systems. But the installation on USB stick is not supported. Installation on removeable devices has many strange problems, with both legacy boot and EFI. > Last year I bought a couple of new AMD desktop systems using APUs > and low-end motherboards. With those LFS is sufficient to boot and > get a network connection (but only for 80x25, using the framebuffer > and later X requires firmware from BLFS). > > Laptops, particularly those without a wired network, may be entirely > different. For wifi wpa-supplicant is needed in BLFS. iwd may be a better alternative since it doesn't require libnl. But unfortunately iwd doesn't work well with NetworkManager on my machine. And for some ADSL or cable modem (without router functionality) ppp and rp-pppoe (it's even beyond BLFS) may be needed. -- 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] grub with uefi for LFS 10?
On 2020-08-02 17:08 +0200, Alexey Orishko via lfs-dev wrote: > On Sat, Aug 1, 2020 at 11:49 PM Bruce Dubbs via lfs-dev > wrote: > > The only reason to use uefi is if you want to dual boot to Windows. It > > complicates LFS and will interfere with learning how simple a boot can be. > > > >-- Bruce > > I was about to post a question, when I saw this discussion. There > might be other reasons > beyond dual-boot - incompatibility with legacy boot devices. > I've recently got Lenovo Thinkbook 13s-IML laptop and I'm unable to > boot LFS 9.1 on it at all. > I planned to replace W10 with BLFS build, but decided to try USB stick > first. It boots fine > on ThinkPad T450s, but Thinkbook 13s. This laptop has NVMe as a boot > disk with W10, > secure boot=off, boot mode legacy first. > Each time I end up in Boot manager GUI with USB stick as an option, > but after a few > seconds it returns to the same screen. Grub stage 1 never shown. > There only one thing I didn't try is EFI boot option in LFS due to > fragmented info > and time required to make it right. > Since majority of new laptops have EFI, it would really help to have > EFI section as a > default option in the book. It's nearly impossible. If we do that we'll have to introduce at least five new packages: dosfstools, popt, pciutils, efivar, and efibootmgr. Pciutils is recommended to be installed along with "which" (it's a package's name), and one of wget/curl/lynx to make update-pciids script usable. And, to make grub menu "showing normal" we'll need freetype. Freetype has a circular dependency with harfbuzz. Harfbuzz requires glib, graphite, and ICU to be fully functional. We have two options: (1) Add all these packages into LFS. (2) Install an "incomplete" version of pciutils/freetype in LFS, and rebuild/tweak them in BLFS. Both of them are stupid IMO. And, if we add some packages to LFS, every LFS user will have to build them. The readers who don't need EFI will be annoyed. meson/ninja already annoyed the readers using sysvinit. If we try not to annoy people, and put some "optional" packages in LFS, the same package must be in LFS and BLFS at same time. Then the maintainance burden and confusion would be unacceptable. > Another suggestion I have regarding initrd: since grub config is > created in LFS book, > it would be nice to move initramfs from BLFS ch.5 to ch8 LFS. It would > make changing > of boot procedure complete in LFS instead of BLFS. > Due to dependency cpio has to be built in LFS as well (and possible > lz4 for future compatibility). In this case I'm annoyed :). I don't use initramfs and why should I install cpio? > I could try EFI variant on Thinkbook 13s laptop if you decide to > include EFI in the new book > (or dev. version of the book) I'll update the hint after I build LFS with Glibc-2.32. We can't just squeeze everything into LFS because it's needed in some situation. I can assure that wpa-supplicant and make-ca are more widely used than efi-grub. But we don't move them into LFS. -- 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] Expected package changes for LFS-10.0 ?
On 2020-07-28 03:30 +0100, Ken Moffat via lfs-dev wrote: > On Mon, Jul 27, 2020 at 09:05:32PM -0500, Douglas R. Reno via lfs-dev wrote: > > As far as I know, we have another binutils as well (2.35). I think there's a > > new version of Check as well, the kernel, and util-linux. > > > Cheers. I'm on check-0.15.0 at the moment (haven't looked at any > LFS testsuite results yet). Binutils is the sort of thing which > might cause occasional breakage, util-linux less so in terms of > building and testing packages (but potentially more so in terms of > being able to run commands I usually run, of course). Glibc-2.32 will be released on Aug 1st. I suggest to wait for it since anyway we'll have to rebuild everything for 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] su needed in chapter 8 build of gcc but not configured in chapter 7 util-linux
On 2020-07-19 14:07 -0500, Timothy Russo via lfs-dev wrote: > I'm rebuilding LFS, using Thomas' multilib patch, but I checked the standard > publication and it references using su to use the non-privileged account > tester for testing the gcc build. > > In chapter 7 for Util-linux, the default configure options has --disable-su. > I still couldn't get it to work after rebuilding util-linux with su enabled, > but if I used the full path to su, /bin/su, it worked. If I did 'whereis su' > it shows it in /bin, and my path shows /bin as the first option, so not sure > why that wasn't working. Util-linux is irrelevent. su should be provided by Shadow installed in chapter 8. -- 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] Errors with Linux From Scratch Version SVN-20200707
On 2020-07-11 09:54 -0500, Bruce Dubbs via lfs-dev wrote: > On 7/11/20 7:38 AM, Xi Ruoyao via lfs-dev wrote: > > On 2020-07-11 11:28 +, John Frankish via lfs-dev wrote: > > > A couple of errors found: > > > > > > Chapter 6. Cross Compiling Temporary Tools > > > 6.7. File-5.39 > > > > > > Building gives the error: > > > > > > Cannot use the installed version of file (5.37) to > > > cross-compile file 5.39 > > > Please install file 5.39 locally first > > > > > > ..fixed by updating file on the host. > > > > Forcing a exact version of file in Host System Requirements is > > stupid. We'll > > have to install a file for host system in Chap. 5. There is also a FIXME in > > file-5.39/magic/Makefile.am: > > > > > # FIXME: Build file natively as well so that it can be used to compile > > > # the target's magic file; for now we bail if the local version does not > > > match > > > > Could someone give upstream a patch for it? > > I don't know why this is happening in Chapter 6. On my log I have: > > checking whether we are cross compiling... no > > It worked fine for me when the host version of file was 5.38. The script checks if the output of the compiler can be executed. If it can be executed it persumes that we are only "faking" cross compiling. Perhaps the OP is building for i386 on (non-multilib) x86_64 host, which would be a real cross- compilation. I'm not sure if we "offically" support this configuration (building for i386 on x86_64 host OS). But theoretically this configuration should work before cross- chap5. -- 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] Errors with Linux From Scratch Version SVN-20200707
On 2020-07-11 11:28 +, John Frankish via lfs-dev wrote: > A couple of errors found: > > Chapter 6. Cross Compiling Temporary Tools > 6.7. File-5.39 > > Building gives the error: > > Cannot use the installed version of file (5.37) to > cross-compile file 5.39 > Please install file 5.39 locally first > > ..fixed by updating file on the host. Forcing a exact version of file in Host System Requirements is stupid. We'll have to install a file for host system in Chap. 5. There is also a FIXME in file-5.39/magic/Makefile.am: > # FIXME: Build file natively as well so that it can be used to compile > # the target's magic file; for now we bail if the local version does not match Could someone give upstream a patch for it? > Chapter 6. Cross Compiling Temporary Tools > 6.10. Grep-3.4 > > Building pulls in a dep on libpcre from the host, which causes problems later, > but can be fixed with "--disable-perl-regexp" It's because configure script picks up the host pkg-config. Other packages may have similar issue. I think we should create a "fake" x86_64-lfs-linux-gnu-pkg-config: ln -sv /bin/false /mnt/lfs/tools/bin/x86_64-lfs-linux-gnu-pkg-config > Also, but probably out of scope, > > Chapter 5. Compiling a Cross-Toolchain > 5.5. Glibc-2.31 > > Fails for arm (RPi) with a long double error fixed with an upstream patch: > > https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html Glibc-2.32 will be released soon (the scheduled date is Aug. 1st). -- 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] Some comments on the test results.
ported' (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 -- 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] 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
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_BASHR
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 aff
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 "ex
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 > >
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
[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
[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 binariesfor 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
Re: [lfs-dev] Some comments on the test results.
On 2020-06-19 18:58 +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) > > > > glibc-2.31.0 > > > > > > We say "misc/tst-ttyname is known to fail in the LFS chroot > > environment." But for me it was skipped (I'm running a 5.7.2 > > kernel, with 5.7.2 headers and 5.7 iproute2). > > > > But my log says > > 5102 PASS > > 44 UNSUPPORTED > > 16 XFAIL > >2 XPASS > > > > And misc/tst-ttyname is now among the unsupported - > > UNSUPPORTED: misc/tst-ttyname > > I have quite different results (was with 5.6.15 kernel and headers, and > iproute2-5.6): > 1 FAIL >5177 PASS > 22 UNSUPPORTED > 17 XFAIL > 2 XPASS > > with > FAIL: misc/tst-ttyname > > I cannot tell why it has run more tests for me than for you (I mean the > 22 less UNSUPPORTED cannot explain the 75 more PASS) > > Note that in a VM with an old debian 8 system (kernel 3.16), I have 24 > UNSUPPORTED and 5175 PASS, otherwise identical. > > > I'm also now wondering about the comment on the rt/tst-cputimer > > tests. I don't have any systems running kernels older than 5.4, but > > the detail suggests that "mid-period" 4.14 and 4.19 stable kernels, > > as well as some or all of 4.20, failed here. Could we not just say > > that some kernels before linux-5.0 cause these tests to fail ? > > Don't remember, so I trust you. This test passed on the 3.16 debian > kernel, though. But some fixes may have been backported. > > > gcc-10.1.0 > > -- > > > > I seem to be getting rather more failures than the book implies, > > although I don't think they are either serious or unexpected. > > > > First, 14 failures i nthe torture test, variants of > > FAIL: gcc.c-torture/compile/limits-exprparen.c > > Isn't it the one that fails when ulimit is not increased? > > > Second, as wel las the 6 locale/get_time test failures I also had > > FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test > > FAIL: 22_locale/numpunct/members/char/3.cc execution test > > Never seen those ones I never seen them. But I haven't tried cross-chap5 for now... > Most often, I have only the 6 22_locale/get_time failures on the > Haswell or 64 bit VM's. > > On the i686 VM, I had 13 errors for libstdc++, but not the same as the > ones you report. > > > bison-3.6.3 > > --- > > > > Here, I strongly disagree that the tests need to be run with -j1. > > > > On my i3 Skylake last December I had to use -j1 to get the package > > to compile, and therefore I also used -j1 on that machine if I ran > > the tests. But on other machines I'm using -j8 both for the compile > > and for the tests (and no failures). > > Could be changed I guess I've tried to run bison tests with -j8. It worked well but I think I just forgot to update the book. > > python-3.8.3 > > > > > > "The test named test_normalization fails because network > > configuration is not completed yet." I assume that the work on > > /etc/hosts has solved this, I have: > > > > 0:01:42 load avg: 6.94 [369/423] test_normalization passed -- > > running: test_concurrent_futures (1 min 38 sec), > > test_multiprocessing_spawn (1 min 33 sec) > > > > and at the end it reported SUCCESS before listing the skipped tests. > > > > Not run those since the book tells not to run them I updated the book to tell it can be run. And the note about "pydebug" in BLFS is also outdated. > > acl-2.2.53 (tested after coreutils) > > -- > > > > In the past I'd assumed that the two failures I was seeing > > [test/root/permissions.test and test/root/setfacl.test ] were because > > I didn't use ACLs (although ext4 supports them), but that was > > probably a mistaken assumption. Anyway, now I don't have any > > failures in acl. > > Not run either > > > util-linux-2.35.2 > > - > > > > I have to admit that this is my first build with this version, I'd > > managed to miss the change to it. I see that we use 'make -k check' > > in the expectation that things may fail. And I do get one failure: > > > > FAILED (column/invalid-multibyte) > > > > ISTR that has happened in the past, and I had the impression that > > the cross- changes had fixed it, but maybe I'm mistaken. > > For me they now all pass (on all my machines). Note that I do not use > any special CFLAGS. Those are all jhalfs builds. The cpu is exactly the > same as yours. > > Pierre > -- 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] a typo in Toolchain Technical Notes?
There is a table: Stage Build HostTarget Action 1 A A B build cross-compiler cc1 using ccA on machine A 2 A B B build cross-compiler cc2 using cc1 on machine A 3 B C C build compiler ccC using cc2 on machine B Should stage 2 be "A B C"? Without a compiler targeting C we can't build ccC, which should runn on C. -- 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] ANNOUNCEMENT - Major Proposed Changes to LFS
On 2020-06-15 15:09 +0800, Kevin Buckley via lfs-dev wrote: > On Sat, 13 Jun 2020 at 20:46, Bruce Dubbs via lfs-dev > wrote: > > In the last few weeks, the LFS editors have been working on a major > > overhaul of LFS. This work can be reviewed at > > > > http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/ > > > > Was there an SVN reference (branch) to pull the sources from? > > > We welcome comments and criticisms large and small. > > > >-- Bruce > > These comments (or maybe criticisms - your interpretation: your rules) > based on a very quick speed read: please take that into consideration > when deciding. > > I'd like to see the "cross-compiling 101" sections, so > > Introduction > Toolchain Technical Notes > General Compilation Instructions > > in "chapter" 5, separated out from the package build sections there. > > Appreciate they would make for a very small introductory chapter > but it somehow feels wrong as it is. > > Not sure if I'd favour the Pass1 and Pass2 sections all being within > the same chapter or not though, or how one would entitle a chapter > that just contained just those five package builds, plus yet another > Introduction. > > I am also aware that Ninja and Meson are still only "required" for > the SystemD version, but that LFS has decided to build packages > in the SysV revision with them, even though all required packages > can still be built using an Autotools-based approach. > (I 'm sure that claim is soon to be rendered invalid though?) > > I appreciate there's a perception that the SysV and SysD books > should align as much as possible, indeed I've even got some > packages re-ordered on the basis of that view, but I'm less > convinced that the SystemD tail should wag the LFS dog. > > Given that LFS used to start from the view that one only built > what was needed to build the LFS-system, and never warming > to the systemd camp fire, i've always felt Ninja and Meson to be > a kind of feature-creep and so was wondering if that could be > made more explicit, so that people could see that Ninja and Meson > could happily be left out until BLFS. > (Though there's no getting away from them there: more's the pity!) We can throw a note there in SysV book, just like the note in Vim page (Vim is neither strictly "required", considering the dependencies). > Then again, I could make the same claim for Intltool and a > couple of other packages related to it. > > Looking forwards to trying it out though, > Kevin -- 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] ANNOUNCEMENT - Major Proposed Changes to LFS
On 2020-06-14 10:49 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/14/20 8:35 AM, Pierre Labastie via lfs-dev wrote: > > On Sun, 2020-06-14 at 15:15 +0200, Pierre Labastie via lfs-dev wrote: > > > I am currently testing whether moving iana-etc before gcc may allow > > > tests to pass, as reported by Joe Locash. If so, I'll commit it. > > > > > > > Hmm, having iana-etc does not change anything to the > > "22_locale/time_get/..." failures, and there is still one > > failure in experimental/net/internet/resolver, even with a real > > /etc/host installed! > > Some details about the 22_locale/time_get/..." failures in gcc's > libstdc++ tests. > > They all revolve around two files in the same way: > > libstdc++-v3/testsuite/22_locale/time_get/get_time/char/2.cc > libstdc++-v3/testsuite/22_locale/time_get/get_time/wchar_t/2.c > > They both do: > >iterator_type is_it20(iss); >tm time20; >errorstate = good; >tim_get.get_time(is_it20, end, iss, errorstate, ); >VERIFY( time20.tm_sec == time_bday.tm_sec ); >VERIFY( time20.tm_min == time_bday.tm_min ); >VERIFY( time20.tm_hour == time_bday.tm_hour ); >VERIFY( errorstate == ios_base::eofbit ); > > The failure is in the last VERIFY macro. > > I've tried to trace the logic of the tim_get.get_time function, but it's > complicated. > > If that last VERIFY is commented out or changed to !=, then all the > time_get failures go away. It's GCC PR71367: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 -- 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] Future for LFS
On 2020-06-13 07:22 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/13/20 7:03 AM, William Harrington via lfs-dev wrote: > > > > > On Jun 12, 2020, at 23:40, Andrew Nevai via lfs-dev < > > > lfs-dev@lists.linuxfromscratch.org> wrote: > > > > > > I will also keep it short. Do not ever use the word "nazis" again on > > > this list. Nobody here deserves to be called that. > > > > > > Andrew > > > > > > # I’ll keep it short and make all of you top level reply nazis angry. > > > # Why isn’t LFS supporting ARM? > > > -- > > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > > FAQ: http://www.linuxfromscratch.org/faq/ > > > Unsubscribe: See the above information page > > > > Very well. I shall not use a word. So everyone decided to take the effort > > and have a Systemd book but not ARM. On behalf of the LFS user base, no ARM. > > The systemd versions of LFS and BLFS basically take the full time effort > or one LFS editor. Are you volunteering to do that for ARM? I think to reduce the work of editors we'll need some CI system. When we get an update we just push it into a "testing" branch and let CI run a ALFS build. When CI reports OK we merge the branch. But for ARM we don't even have a hardware :(. Is there any ARM hardware recommended for LFS development? (Should be fast enough to rebuild LFS, maybe daily.) -- 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] Housekeeping to satisfy latest LFS package removals (Flex)
On 2020-05-30 14:48 -0400，Ryan Marsaw via lfs-dev wrote: > Hello. > > Now that Flex is no longer installed in Chapter 5, one line needs to be > removed from Chapter 6.6: "Creating Essential Files and Symlinks" > > ln -sv /tools/lib/libfl.so* /usr/lib Sorry for forgot it. Done at r11880. -- 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: some improvements to LFS book
On 2020-05-15 15:09 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-11 23:05 +0800, Xi Ruoyao via lfs-dev wrote:
> > On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> > > On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > > > On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> > > > > I just redone LFS build for GCC-10.1.0. I proposed several
> > > > > improvements during
> > > > > the process:
> > > > >
> > > > > At first, some changes suggested by Firas:
> > > > >
> > > > > 1. Remove bzip2 in Chap. 5. No other changes needed.
> > > >
> > > > decreases the total number of SBUs by 0.1 :) why not, though
> > > >
> > > > > 2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to
> > > > > satisify
> > > > > it.
> > > > > Notes:
> > > > > (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
> > > > > module we don't
> > > > > need.
> > > > > (2) We moved readline before bc to satisify GNU bc, but now Gavin's
> > > > > bc doesn't
> > > > > need readline.
> > > >
> > > > good point
> > > >
> > > > > (3) It slightly reduces the functionality of Chap. 5 bash. Long
> > > > > command lines
> > > > > won't be wrapped automatically anymore.
> > > >
> > > > It does much more than that if the terminfo database is not installed:
> > > > no backspace (more exactly, backspace outputs only a space forward...)
> > > > left and right arrows not functional.
> > > > In short, no way to correct a typo
> > > >
> > > > can be Ok if scripting though
>
> So I'll not do that.
In a recent thread we discovered gettext somehow depends on ncurses. So it
should not be done, at all.
> > > > > 3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so
> > > > > `ranlib` and
> > > > > `ar` can link to libfl.so. It seems bison test suite does not
> > > > > depends on flex
> > > > > any more.
> > > >
> > > > bison chapter 6 will be built after flex anyway, if we do the above, so
> > > > whether it depends on it or not is not important.
> > > >
> > > > > However Firas' other suggestions are proved to be impossible. Glibc
> > > > > requires
> > > > > bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
> > > > > so all of
> > > > > them need to stay in Chap. 5. Util-linux can't be removed from Chap.
> > > > > 5 due to
> > > > > its circular dependency with systemd/eudev.
> > > > >
> > > > > And:
> > > > >
> > > > > 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
> > > > > use zstd to
> > > > > compress LTO stream.
> > > >
> > > > definitely to be done, independently on the other points.
> > > >
> > > > > 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It
> > > > > seems
> > > > > unneeded now.
> > > > >
> > > > > 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
> > > > >
> > > > > 7. Add:
> > > > >
> > > > >mkdir /tools/lib/locale
> > > > >localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
> > > > >
> > > > > into Chap. 5 Glibc. It will satisfy Chap. 6 man-db test.
> > > >
> > > > Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
> > > > archive
> > > >
> > > > allows also all bison tests to pass
> > > >
> > > > > 8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
> > > > > "Cleaning
> > > > > up" section.
> > > >
> > > > Independent on the other points and should be done for sure.
> > > >
> > > > > Are they OK to be committed into trunk?
> > > >
> > > > I'd say point 2 shouldn't not be committed, or only with some tweak of
> > > > the terminfo database...
> > > >
> > > > among the other points:
> > > >
> > > > - 4 and 8 should be done for sure.
> &g
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote: > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev > wrote: > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > > > wrote: > > > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > > > wrote: > > > > > Hey there, > > > > > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > > > on the host system. > > > > > > > > > > Apparently, failure to create this link causes > > > > > configure/build/linking > > > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > > > > > > > I'm not really sure why this link is required though. I understand > > > > > that it's currently a must to build LFS (apparently not much > > > > > explanation is provided to how GCC/Binutils searching/configuring > > > > > works with regards to directory layout,so we need to cover for > > > > > $LFS/tools and /tools with the latter being silently used in some > > > > > places to make the toolchain build; by silently I mean automatically > > > > > appended to $LFS without knowing when/where so it won't error out), > > > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > > > and Glibc remove the need for such symlink? > > > > No, unless we use some DESTDIR installation. It's Pierre's cross Chapter 5 > > experiment: > > > > http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > > I've checked piere's modifications, and they're most welcome, but I'm > only talking about removing the `/tools` symlink without touching > anything else. > > I don't think GCC needs its source modifications be changed (meaning > that we'll still use the regular `/tools/lib`), and I think that's > made possible because sysroot is actually appended before ld's search > path (one thing that might require minor modification is that when ld > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying > `t-linux64` to use `../lib` instead of `../lib64`) path relative to > where it is, it won't get the right `lib` folder as it gets to > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the > configuration passed to the toolchain components. It's not about library search path. It's about GCC internal executable path. When you configure GCC with --prefix=/mnt/lfs/tools, the path "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded into executables gcc, g++, etc. When this GCC build is used, it searches internal executables cc1, cc1plus, etc. in this path. So if we use -- prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot (gcc will say something like 'cc1 not found'). And there is a GCC library path "/mnt/lfs/tools/lib/gcc/x86_64-linux-gnu/10.1.0" contains libgcc libraries and headers. It's also hardcoded. One way to solve this is to add CC="gcc -B /tools/libexec/gcc/x86_64-linux- gnu/10.1.0 -L /tools/lib/gcc/x86_64-linux-gnu/10.1.0 -I /tools/lib/gcc/x86_64- linux-gnu/10.1.0/include" in early Chapter 6 packages. I believe such a long $CC is stupid. Another way, already said by Pierre, is "ln -sv /tools /mnt/lfs" in chroot environment. > > > > > These errors can be evaded by closely examining > > > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > > > > to "../../lib" based on where ld is searching), along with > > > > > `--with-lib-path` in binutils pass 1. > > > > > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > > > > > Thanks for your time and effort. > > > > > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > > > we have /tools. But then, when going to chapter 6, some search paths > > > > would contain $LFS/tools, that we do not have in chroot. That's the > > > > reason to have the link and use it in chapter 5. > > > > > > > > > > > > Note, we could maybe create /mnt/lfs in chroot, a
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > wrote: > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > wrote: > > > Hey there, > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > on the host system. > > > > > > Apparently, failure to create this link causes > > > configure/build/linking > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > > > I'm not really sure why this link is required though. I understand > > > that it's currently a must to build LFS (apparently not much > > > explanation is provided to how GCC/Binutils searching/configuring > > > works with regards to directory layout,so we need to cover for > > > $LFS/tools and /tools with the latter being silently used in some > > > places to make the toolchain build; by silently I mean automatically > > > appended to $LFS without knowing when/where so it won't error out), > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > and Glibc remove the need for such symlink? No, unless we use some DESTDIR installation. It's Pierre's cross Chapter 5 experiment: http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > These errors can be evaded by closely examining > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > > to "../../lib" based on where ld is searching), along with > > > `--with-lib-path` in binutils pass 1. > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > Thanks for your time and effort. > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > we have /tools. But then, when going to chapter 6, some search paths > > would contain $LFS/tools, that we do not have in chroot. That's the > > reason to have the link and use it in chapter 5. > > > > > > Note, we could maybe create /mnt/lfs in chroot, and have: > > /mnt/lfs/tools->/tools in chroot. > > Never tried. > > > > Pierre > > > > > > -- > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > FAQ: http://www.linuxfromscratch.org/faq/ > > Unsubscribe: See the above information page > > I understand that due to chroot environment $LFS/tools will eventually > become /tools and the path to the link inside every binary produced in > Chapter 5 (due to the modification of the GCC sources) will thus > remain valid inside chroot, but wouldn't it be better to spare the > host system? Now we know it works well. And we know there is no other packages using /tools (we've discussed this in lfs-dev long times ago). /tools is a simple symlink in host so it's easy to remove. > Also I apologize for the error in the name of this message as it's > supposed to be /tools and not /toolchain. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] proposal: some improvements to LFS book
On 2020-05-11 23:05 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> > On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > > On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> > > > I just redone LFS build for GCC-10.1.0. I proposed several
> > > > improvements during
> > > > the process:
> > > >
> > > > At first, some changes suggested by Firas:
> > > >
> > > > 1. Remove bzip2 in Chap. 5. No other changes needed.
> > >
> > > decreases the total number of SBUs by 0.1 :) why not, though
> > >
> > > > 2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to
> > > > satisify
> > > > it.
> > > > Notes:
> > > > (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
> > > > module we don't
> > > > need.
> > > > (2) We moved readline before bc to satisify GNU bc, but now Gavin's
> > > > bc doesn't
> > > > need readline.
> > >
> > > good point
> > >
> > > > (3) It slightly reduces the functionality of Chap. 5 bash. Long
> > > > command lines
> > > > won't be wrapped automatically anymore.
> > >
> > > It does much more than that if the terminfo database is not installed:
> > > no backspace (more exactly, backspace outputs only a space forward...)
> > > left and right arrows not functional.
> > > In short, no way to correct a typo
> > >
> > > can be Ok if scripting though
So I'll not do that.
> > > > 3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so
> > > > `ranlib` and
> > > > `ar` can link to libfl.so. It seems bison test suite does not
> > > > depends on flex
> > > > any more.
> > >
> > > bison chapter 6 will be built after flex anyway, if we do the above, so
> > > whether it depends on it or not is not important.
> > >
> > > > However Firas' other suggestions are proved to be impossible. Glibc
> > > > requires
> > > > bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
> > > > so all of
> > > > them need to stay in Chap. 5. Util-linux can't be removed from Chap.
> > > > 5 due to
> > > > its circular dependency with systemd/eudev.
> > > >
> > > > And:
> > > >
> > > > 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
> > > > use zstd to
> > > > compress LTO stream.
> > >
> > > definitely to be done, independently on the other points.
> > >
> > > > 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It
> > > > seems
> > > > unneeded now.
> > > >
> > > > 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
> > > >
> > > > 7. Add:
> > > >
> > > >mkdir /tools/lib/locale
> > > >localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
> > > >
> > > > into Chap. 5 Glibc. It will satisfy Chap. 6 man-db test.
> > >
> > > Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
> > > archive
> > >
> > > allows also all bison tests to pass
> > >
> > > > 8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
> > > > "Cleaning
> > > > up" section.
> > >
> > > Independent on the other points and should be done for sure.
> > >
> > > > Are they OK to be committed into trunk?
> > >
> > > I'd say point 2 shouldn't not be committed, or only with some tweak of
> > > the terminfo database...
> > >
> > > among the other points:
> > >
> > > - 4 and 8 should be done for sure.
> > > - I've not tested 5 and 6, but I guess you have tested them, so go for
> > > them too
> > > - I'd rather use the link for point 7 (less instructions in chap 5
> > > glibc). This is just one more line in "creating essentials symlinks and
> > > files".
>
> I agree that a link is better.
>
> > > - I'm not sure about point 3: building flex only once is tempting, but
> > > can the tests be run, and is flex the same as if rebuilt at the end of
> > > chap 6?
>
> I'll retry 3, 5 and 6 again to make sure, ...
For 3:
They are same (`diff` returns 0 for flex and libfl.so). But I'm using some
CFLAGS w/o `-g` so the comparsion doesn't include debug information.
For 6:
Definitly OK.
For 5:
The configure script actually doesn't use pkg-config to find packages at all.
> > > - Point 1 improves only marginally the build time, but why not?
> >
> > Can we hold off on these changes for a week or so until we get BLFS
> > built with gcc10?
>
> ... in the meantime we can get BLFS built with gcc 10 :).
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
>
--
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] CFLAGS in fixing up for gcc-10.
On 2020-05-13 23:46 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/13/20 11:33 PM, Ken Moffat via lfs-dev wrote:
> > I notice that in some places people have overridden any existing
> > CFLAGS when adding -fcommon. In most places, for those of us who
> > care the fix is obvious (CFLAGS="$CFLAGS -fcommon"). One or two
> > packages will turn out to be more painful.
> >
> > The first I've found is freeglut, where the book uses
> >-DCMAKE_C_FLAGS=-fcommon
> >
> > For people without any existing CFLAGS, that does the right thing
> > and respects the -O3 etc from specifying a Release build (seen by
> > using 'make VERBOSE=1') but for people who have extra flags such as
> > "-march=native -D_FORTIFY_SOURCE=2" those just get thrown away.
> >
> > I'd assumed I could add
> > -DCMAKE_CFLAGS="$CFLAGS -fcommon"
> >
> > but if I do that, cmake tells me that CFLAGS was not referenced.
> >
> > In this case, I am getting the right results (testing on a gcc-9
> > system) with:
> >
> > CFLAGS="${CFLAGS} -fcommon" \
> > cmake -DCMAKE_INSTALL_PREFIX=/usr \
> >-DCMAKE_BUILD_TYPE=Release \
> >-DFREEGLUT_BUILD_DEMOS=OFF \
> >-DFREEGLUT_BUILD_STATIC_LIBS=OFF \
> >-Wno-dev ..
> >
> > Can I ask people to at least *consider* not trashing a user's
> > specified CFLAGS ?
>
> Yes, we can do that, but right now we are trying to just get everything
> to build with gcc10. When that is done, we can probably review and do
> 'grep -r CFLAGS; in the book's xml top and do the right thing where we
> have had to make changes.
>
> Also as new package releases address gcc10, we can probably remove a lot
> of the CFLAGS entries that we've been making.
I don't like -fcommon. It's actually changing C semantics. The correct thing
to do is to fix the code (like what we do for gdbm in LFS).
Though we can simply add this workaround for now...
--
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: some improvements to LFS book
On 2020-05-11 09:19 -0500, Bruce Dubbs via lfs-dev wrote:
> On 5/11/20 8:23 AM, Pierre Labastie via lfs-dev wrote:
> > On Mon, 2020-05-11 at 19:51 +0800, Xi Ruoyao via lfs-dev wrote:
> > > I just redone LFS build for GCC-10.1.0. I proposed several
> > > improvements during
> > > the process:
> > >
> > > At first, some changes suggested by Firas:
> > >
> > > 1. Remove bzip2 in Chap. 5. No other changes needed.
> >
> > decreases the total number of SBUs by 0.1 :) why not, though
> >
> > > 2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to
> > > satisify
> > > it.
> > > Notes:
> > > (1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one
> > > module we don't
> > > need.
> > > (2) We moved readline before bc to satisify GNU bc, but now Gavin's
> > > bc doesn't
> > > need readline.
> >
> > good point
> >
> > > (3) It slightly reduces the functionality of Chap. 5 bash. Long
> > > command lines
> > > won't be wrapped automatically anymore.
> >
> > It does much more than that if the terminfo database is not installed:
> > no backspace (more exactly, backspace outputs only a space forward...)
> > left and right arrows not functional.
> > In short, no way to correct a typo
> >
> > can be Ok if scripting though
> >
> > > 3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so
> > > `ranlib` and
> > > `ar` can link to libfl.so. It seems bison test suite does not
> > > depends on flex
> > > any more.
> >
> > bison chapter 6 will be built after flex anyway, if we do the above, so
> > whether it depends on it or not is not important.
> >
> > > However Firas' other suggestions are proved to be impossible. Glibc
> > > requires
> > > bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred)
> > > so all of
> > > them need to stay in Chap. 5. Util-linux can't be removed from Chap.
> > > 5 due to
> > > its circular dependency with systemd/eudev.
> > >
> > > And:
> > >
> > > 4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and
> > > use zstd to
> > > compress LTO stream.
> >
> > definitely to be done, independently on the other points.
> >
> > > 5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It
> > > seems
> > > unneeded now.
> > >
> > > 6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
> > >
> > > 7. Add:
> > >
> > >mkdir /tools/lib/locale
> > >localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
> > >
> > > into Chap. 5 Glibc. It will satisfy Chap. 6 man-db test.
> >
> > Or link /tools/share/locale/locale-archive->/usr/share/locale/locale-
> > archive
> >
> > allows also all bison tests to pass
> >
> > > 8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in
> > > "Cleaning
> > > up" section.
> >
> > Independent on the other points and should be done for sure.
> >
> > > Are they OK to be committed into trunk?
> >
> > I'd say point 2 shouldn't not be committed, or only with some tweak of
> > the terminfo database...
> >
> > among the other points:
> >
> > - 4 and 8 should be done for sure.
> > - I've not tested 5 and 6, but I guess you have tested them, so go for
> > them too
> > - I'd rather use the link for point 7 (less instructions in chap 5
> > glibc). This is just one more line in "creating essentials symlinks and
> > files".
I agree that a link is better.
> > - I'm not sure about point 3: building flex only once is tempting, but
> > can the tests be run, and is flex the same as if rebuilt at the end of
> > chap 6?
I'll retry 3, 5 and 6 again to make sure, ...
> > - Point 1 improves only marginally the build time, but why not?
>
> Can we hold off on these changes for a week or so until we get BLFS
> built with gcc10?
... in the meantime we can get BLFS built with gcc 10 :).
--
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] proposal: some improvements to LFS book
I just redone LFS build for GCC-10.1.0. I proposed several improvements during
the process:
At first, some changes suggested by Firas:
1. Remove bzip2 in Chap. 5. No other changes needed.
2. Remove ncurses in Chap. 5. Move Chap. 6 readline after ncurses to satisify
it.
Notes:
(1) Chap. 5 Python 3 can be built w/o ncurses, just lacking one module we don't
need.
(2) We moved readline before bc to satisify GNU bc, but now Gavin's bc doesn't
need readline.
(3) It slightly reduces the functionality of Chap. 5 bash. Long command lines
won't be wrapped automatically anymore.
3. Remove flex in Chap. 5. Move Chap. 6 flex before Binutils so `ranlib` and
`ar` can link to libfl.so. It seems bison test suite does not depends on flex
any more.
However Firas' other suggestions are proved to be impossible. Glibc requires
bison, gzip, gettext, perl, texinfo, python, and xz (to be untarred) so all of
them need to stay in Chap. 5. Util-linux can't be removed from Chap. 5 due to
its circular dependency with systemd/eudev.
And:
4. Move Chap. 6 zstd before GCC, so GCC can link to libzstd.so and use zstd to
compress LTO stream.
5. Remove PKG_CONFIG_PATH=/tools/lib/pkgconfig in Chap. 6 kbd. It seems
unneeded now.
6. Remove PERL5LIB=$PWD/tests/ in Chap. 6 make. It is unneeded now.
7. Add:
mkdir /tools/lib/locale
localedef -i POSIX -f UTF-8 C.UTF-8 2> /dev/null || true
into Chap. 5 Glibc. It will satifisy Chap. 6 man-db test.
8. Remove libctf{,-nobfd}.a (along with libbfd.a and libopcodes.a) in "Cleaning
up" section.
Are they OK to be commited into trunk?
--
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] chapter6: move Zstd before GCC?
Now GCC optionally depends on zstd (using it like zlib to compress LTO IR). Should we move zstd before GCC? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Reduce Temporary System Components and Reorder Basic System Software
On 2020-05-06 14:16 +0300, Firas Khalil Khana via lfs-dev wrote: > On Wed, May 6, 2020 at 1:56 PM Xi Ruoyao via lfs-dev wrote: > > Pierre recently discovered the circular dependency between eudev (in > > Sysvinit > > book) and util-linux: > > > > > util-linux uses libudev (eudev) in lsblk (with fallback to libblkid from > > > util- > > > linux if libudev has not been linked). And udev uses libblkid to find > > > information about some block devices (specialy cdrom_id, ata_id, etc). > > > Note > > > that this is well known and cured in systemd book. > > Oh I forgot that this is related to how Util-linux and e2fsprogs are > configured. So Chapter 5 Util-linux will have to rely on the host's > libudev, while Chapter 6 Util-linux will have to rely on the eudev we > provide. Chap. 5 Util-linux does not use libudev. Since it's temporal we don't need the additional functionality added by linking to libudev in Chapter 5. For your approach, I found some issues preparing it: > 1- Ncurses can be removed? or is it needed for Chapter 5 Python which in turn > is needed for Chapter 6 Glibc? Perhaps it can be removed for those using > different C libraries (e.g. musl)? > > 2- Bash (The chroot environment's shell) can be built without curses support > by passing "--without-curses", until it gets rebuilt again in Chapter 6 with > curses support. > > 3- Bison can be removed, and built only once early in Chapter 6 (twice for > those who want to satisfy flex). > > 4- Flex can be removed, and built only once early in Chapter 6 (after bison, > and before the second build of bison for those who want to satisfy it). Then we need to move bison and flex before Chap. 6 binutils. > 5- Bzip2 can be removed since we're relying on host tools to decompress needed > packages that were downloaded early on (plus it will be built early on in > Chapter 6 so no package should require it). > > 6- I prefer to hostname over coreutils hostname but that's totally optional. > > 7- which can be added after coreutils (some packages may depend on it in the > format of using it inside scripts to fetch available binary versions (gcc with > go support, coreutils?, the Linux kernel (for testing?), but it's pretty > useful once you're in the chroot environment and in the final system as well). > > 8- Gettext can be removed and built early on in Chapter 6. We can't. Glibc needs it to be built. > 9- Gzip can also be removed since we're relying on host tools to decompress > needed packages that were downloaded early on (plus it will be built early on > in Chapter 6 so no package should require it). Then we need to build it before bzip2, in Chap. 6. > 10- Perl can be completely removed and satisfied early on in Chapter 6 before > packages that require it. We can't. Glibc needs it to be built. > 11- Python can be removed? glibc requires it so it can't be removed, but with > other C libraries (e.g. musl) it can be removed and built only when needed in > Chapter 6. We can't. Glibc needs it to be built. > 12- Texinfo can be removed and built early on in Chapter 6. We can't. There is a circular dependency: * Groff needs Texinfo to build its documentation. * Texinfo must be installed after Perl, in Chap. 6 (or it would hardcode /tools/bin/perl into its executables). * Chap. 6 Perl needs Groff to build its man pages. > 13- Util-linux can be removed, but I think certain testing suites require it? > Perhaps for those who are sure that the packages have been built correctly it > can be removed? We can't. There is a circular dependency between Util-linux libraries and Systemd/Eudev. > 14- Xz can be removed and built early on in Chapter 6 since we're relying on > host tools to decompress needed packages that were downloaded early on (plus > it will be built early on in Chapter 6 so no package should require it). We can't. xz-5.2.5.tar.xz needs it to be untared. For 6 and 7, I really don't care. I'll test 1-5, and 9 to see if they are possible. -- Xi Ruoyao School of Aerospace 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] Reduce Temporary System Components and Reorder Basic System Software
On 2020-05-06 13:02 +0300, Firas Khalil Khana via lfs-dev wrote:
> On Tue, May 5, 2020 at 6:40 PM Douglas R. Reno via lfs-dev
> wrote:
> >
> > On 5/5/20 5:49 AM, Firas Khalil Khana via lfs-dev wrote:
> >
> > @Xi,
> >
> > Thanks for taking the time to explain everything, much appreciated!
> >
> >
> > > Then it will be stupidly inconvenience typing commands.
> >
> > It will still get you through until bash is rebuilt again in Chapter 6, with
> > no problems.
> >
> > That being said, I think Ncurses can't be dropped in Chapter 5 because
> > Python in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc to
> > build).
> >
> >
> > > There is some circular dependency between bison and gettext so it's
> > > impossible
> > > to build both of them only once. It's #4634.
> >
> > I've checked this issue and it isn't related to what I've mentioned.
> >
> > I mentioned that the final list in Chapter 5 won't contain Bison, Gettext
> > and Flex, but instead they will be rebuilt early on in Chapter 6 in correct
> > order (Gettext -> Bison -> Flex (-> Bison (Optional for the circular
> > dependency)), so Bison will get to be built before Gettext and in Chapter 6,
> > so #4634 shouldn't appear.
> >
> > > Pierre just added them so Chap. 6 binutils can link to libfl.so. It's
> > > #4631.
> >
> > Again instead of adding more to Chapter 5, just reorder some packages in
> > Chapter 6 to be built early on. In the list I've suggested, both Bison and
> > Flex will be built before binutils so I don't see how #4631 will happen.
> >
> > > To avoid more ICA issues we don't want to move many things too "early".
> >
> > I'm afraid I'm not familiar with this term. I couldn't find it in the
> > "Acronyms and Terms" appendix as well. You mean breakages?
> >
> >
> > > Your distro your rules.
> >
> > I was just pointing out the existence of hostname (from debian), but keeping
> > coreutils the provider for hostname is better and more logical at this
> > point.
> >
> >
> > > Also #4634.
> > Again, 4634 won't happen in the lists I've suggested. There will be no
> > builds of Gettext, Bison and Flex in Chapter 5, and instead they'll be built
> > in the correct order and early on in Chapter 6 (Gettext -> Bison -> Flex
> > (->
> > Bison for those who want to rebuild Bison again when Flex becomes
> > available)).
> > > We don't want many packages too be early in Chap. 6.
> > Why not? Wouldn't it be better and easier to maintain if there were less
> > packages to build, without sacrificing any package but just by simply
> > reordering packages in Chapter 6? Not having to deal with cross packages
> > (like Perl in Chapter 5, for example) is something good.
> > > But we are using glibc. Again, your distro your rules.
> > Yes, at this point Python can't be removed from Chapter 5 because it's
> > needed by Glibc in Chapter 6 which is like the third package to be built
> > there.
> >
> > > We don't want many packages too be early in Chap. 6.
> > Again why not?
> >
> > > Wrong. Systemd or eudev depends on lib{uuid,blkid,mount}.so.
> > Why add Util-linux to Chapter 5, instead of reordering Util-linux to be
> > built before eudev in Chapter 6 then? Again as I said, I think you're doing
> > that to avoid #4637 so I won't argue, but it has to do with how these
> > packages are configured (and that's not the point now).
> >
> > The other problem is that Util-Linux includes some support files (such as
> > files that go in /usr/lib/tmpfiles.d), that are only installed if systemd is
> > present. However, systemd itself requires Util-Linux (similar to eudev I
> > think, it uses it for libmount and libuuid). The way we've always resolved
> > that is to build Util-Linux in Chapter 5 (previously there were more
> > packages that required it), and then build systemd, and then rebuild Util-
> > Linux afterwards.
> >
> > - Doug
> >
> > --
> > http://lists.linuxfromscratch.org/listinfo/lfs-dev
> > FAQ: http://www.linuxfromscratch.org/faq/
> > Unsubscribe: See the above information page
>
> Then why is Util-linux also included in Chapter 5 in the SysVinit
> version of LFS? Shouldn't it suffice to only have it be built in
> Chapter 6?
Pierre recently discovered the circular dependency between eudev (in Sysvinit
book) and util-linux:
> util-linux uses libudev (eudev) in lsblk (with fallback to libblkid from util-
> linux if libudev has not been linked). And udev uses libblkid to find
> information about some block devices (specialy cdrom_id, ata_id, etc). Note
> that this is well known and cured in systemd book.
--
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] Reduce Temporary System Components and Reorder Basic System Software
ary, but if the second build is too different from the first, it may be > a indication of incorrectness. > > Leaving priority and severity to normal. It will be adjusted depending on what > is found. > > Note that what we have allows building the whole blfs, so it is unlikely that > priority and severity go the "high" direction. I should try your approach and do an ICA, and see what will happen. But I'm now busy preparing the problem set for an online programming contest. Maybe I'll have time to do this on May 20. -- 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] Reduce Temporary System Components and Reorder Basic System Software
ving the packages specified > above because they were built beforehand (with the exception of bison for > those who want to build it a second time after flex). How many ICA issues would we catch using this approach? @pierre :). > This can help by greatly reducing the amount of time needed to get the final > system working, and should make things for some packages (perl and python) > easier since they're only built once in the final system when needed (the > final builds should also theoretically be easier because they're native builds > now, removing the need to deal with cross builds of these packages especially > when using other C libraries (e.g. musl)). It's not "the faster the better". If "the faster the better" we can just cross- compile everything in host, and put them altogether. -- 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] Test failure in man-db
On 2020-05-04 04:19 +0100, Ken Moffat via lfs-dev wrote: > On Sun, May 03, 2020 at 09:13:27PM -0500, Bruce Dubbs via lfs-dev wrote: > > On 5/3/20 8:15 PM, Ken Moffat via lfs-dev wrote: > > > > > root in chroot /# export LC_ALL=en_US.iISO-8859-1 && date > > > bash: warning: setlocale: LC_ALL: cannot change locale > > > (en_US.ISO-8859-1): > > > No such file or directory > > > Mon May 4 00:50:46 UTC 2020 > > > > export LC_ALL=en_US.iISO-8859-1 && date > > bash: warning: setlocale: LC_ALL: cannot change locale (en_US.iISO-8859-1): > > No such file or directory > > > > Note the typo. > > > > Yeah, shit happens - I noticed my first attempt had been .SO-8859-1 > and thought I'd fixed it, forgetting this was bash not vim. > > > Is it because the locales are not available until after glibc and then > > leaving/reentering chroot? > > > > -- Bruce > > Possible. A bit of a pain if that is so. Still building /tools for > this run, then I'll let it run (following xry111's suggestion to add > the locale in /tools glibc, although I now doubt that - see what I > just posted). > > Assuming bison still fails its tests, I'll try that. > > Doesn't really explain why man-db has sometimes failed, but passed > other times (for various builders). Maybe there is something else > there. In sysv book, there was no util-linux in chap. 5 (until Pierre added them to fix problems found by ICA). So the tests using util-linux tools would be skipped. -- 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] Test failure in man-db
On 2020-05-04 02:15 +0100, Ken Moffat via lfs-dev wrote:
> On Sun, May 03, 2020 at 04:18:57AM +0100, Ken Moffat via lfs-dev wrote:
> > I'm building with LFS as at 25th April. My previous build was in
> > early April, and I think this is the first time I've seen a failure
> > in the man-db tests. With man-db-2.9.1 :
> >
> > FAIL: man-missing-locales
> >
> > and src/tests/test-suite.log has:
> >
> > FAIL: man-missing-locales
> > =
> >
> > col: failed on line 319: Invalid or incomplete multibyte or wide character
> > man: command exited with status 127: LC_CTYPE=en_US.UTF-8 col -b -p -x | sed
> > -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D; }'
> > FAIL: missing locales
> > FAIL man-missing-locales (exit status: 1)
> >
> > Given that things have changed since my previous build, is anyone
> > else seeing this ? I suspect the error might be "mine, all mine",
> > so I'm reluctant to add to the noise by reporting iti upstream
> > unless it really is common. Looking at my glibc log I did
> > apparently install the en_US.UTF-8 locale.
> >
> > ĸen
>
> Update: I'm doing a fresh build to look at the test failures in this
> and in bison (and also to make sure I've fixed my own screw-up in
> removing the symlinked headers before rebuilding util-linux).
>
> Got to bison, failures as before. First is
>
> 131. diagnostics.at:107: testing Warnings ...
> ./diagnostics.at:107: LC_ALL="$locale" bison -fcaret --color=debug -Wall
> input.y
> --- experr 2020-05-03 23:20:06.028040360 +
> +++ /building/bison-3.5.4/tests/testsuite.dir/at-groups/131/stderr 2020-
> 05-03 23:20:06.057040734 +
> @@ -1,3 +1,4 @@
> +/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
> input.y:9.12-14: warning: symbol FOO redeclared
> [-Wother]
> 9 | %token FOO FOO FOO
>|^~~
> 131. diagnostics.at:107: 131. Warnings (diagnostics.at:107): FAILED
> (diagnostics.at:107)
>
> So, bothi bison and man-db test failures are for en_US.{UTF-8,utf8}
> variants. The capitalized version is definitely installed, accoding
> to my log from glibc.
So I think the issue is: we are using chapter 5 bash for bison, and chapter 5
util-linux for man-db. Chapter 5 tools' locale archive is
/tools/lib/locale/locale-archive, which is not installed.
Maybe installing en_US.UTF-8 locale in chap. 5 glibc would solve this problem.
--
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] Modified build of LFS using pure cross-compilation and sysroot
On 2020-05-01 20:51 -0500, Douglas R. Reno via lfs-dev wrote: > On 5/1/20 8:53 AM, Pierre Labastie via lfs-dev wrote: > >cons: chroot is entered in the middle of chapter 5 (maybe chapter 5 > > should be split), the debug sections of several packages reference > > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2 > > needs "enable-shared". > > The debug information being broken is a major dealbreaker for me. I use > the debug information from these packages semi-frequently and not having > that at my disposal would make things a lot tougher for me. Hopefully we can fix the debug info with some -ffile-prefix-map parameter in $CC. -- 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] gnome-shell failure building man page
On 2020-04-13 12:01 +1000, Christoph Willing via lfs-dev wrote: > gnome-shell-3.36.1 from svn Version 2020-04-11 fails with: > > [19/187] Generating gnome-extensions.1 with a custom command. > FAILED: subprojects/extensions-tool/man/gnome-extensions.1 > /usr/bin/a2x -D subprojects/extensions-tool/man --xsl-file > ../subprojects/extensions-tool/man/stylesheet.xsl -f manpage > ../subprojects/extensions-tool/man/gnome-extensions.txt > File "/usr/bin/a2x", line 76 > print '%s: %s' % (PROG,msg) > ^ > SyntaxError: invalid syntax > > > I initially worked around this by adding -Dman=false to the command line > i.e. > > mkdir build && \ > cd build && \ > meson --prefix=/usr -Dsystemd=false -Dman=false .. && \ > ninja > > That enabled the build to succeed, although without addressing the > underlying a2x problem. > > Looking at the a2x problem, I believe the invalid syntax problem is > because I have: > /usr/bin/python -> python3 Don't do that. > If I change that to: > /usr/bin/python -> python2 > > then the build succeeds (although with a warning which I don't see when > /usr/bin/python -> python3): > [40/187] Generating gnome-extensions.1 with a custom command. > a2x: WARNING: --destination-dir option is only applicable to HTML based > outputs > > > I don't recall how /usr/bin/python became symlink to python3 - perhaps > it should be to python2. Maybe that should be made explicit somewhere? BLFS book explicitly said asciidoc deps on Python 2. > > BTW I see there is an asciidoc-py3 available at: > https://github.com/asciidoc/asciidoc-py3 > > Is it worth moving to that? It's 9.0.0rc2. We are waiting for 9.0.0 release. I'll create a ticket to track. -- 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] x86_64-bit dynamic linker location
On 2020-04-07 21:37 -1000, Dean Takemori via lfs-dev wrote: > For x86_64 builds, LFS patches gcc to set the default directory name for 64- > bit libraries to “lib” instead of “lib64” (eg in chapter 5.5.1, 5.10.1 and > 6.25.1) by patching gcc/config/i386/t-linux64 > > But the location of the dynamic linker is left in /lib64, meaning a “stub > directory” /lib64 ends up being created and then a compatibility symlink added > in chapter 6.9.1 > > > Is there any reason to not additionally patch gcc and glibc to have the > x86-64 > dynamic linker reside in /lib? Short answer: don't do that. Long answer: the full path to the ELF interpreter is hardcoded in every ELF executables. If we use a path different to other distros, we can't run the executables compiled in our system on other distros, vice versa. So the path have to be specified in a standard, which is Linux Standard Base. LSB 2.0.0 mandates to use /lib64/ld-linux-x86-64.so.2 on AMD64. And LSB 3.0.0+ mandates to use /lib64/ld-lsb-x86-64.so.3. If you don't care LSB or compatibility with other distros, you can do whatever you want (your distro, your rules). But we can't do it in the book. -- 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] Linux kernel policy
On 2020-03-31 23:35 +0100, Ken Moffat via lfs-dev wrote: > On Tue, Mar 31, 2020 at 11:37:15AM -0500, Bruce Dubbs via lfs-dev wrote: > > On 3/31/20 4:14 AM, Pierre Labastie via lfs-dev wrote: > > > On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > > > > On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > > > > > > > > For 5.4 LTS, we got 21 releases in this year, and 12 releases since > > > > Feb. 1st. > > > > No significant improvement. LTS meaning continuing maintenance so > > > > we'll still > > > > get one release for each severe bug (even if it's a bug in a strange > > > > server > > > > motherboard). > > > > > > > > I think we can just hold on kernel 5.x.0 for the development book > > > > unless there > > > > is a bug making it unusable. (There is already a note telling the > > > > audience to > > > > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. > > > > > > > > > > I'd say that what we have (update the kernel to latest when updating > > > other parts of the book) is not so bad, except we should refrain to > > > update to whatever.0 versions. It's not because the maintainers have > > > done some mistake once (modifying a driver between the last rc and the > > > release IIUC), that they always will do, but we should consider > > > whatever.0 versions are still "development" (not only for kernel > > > actually). Oh I didn't know that. A similar issue is mesa-x.y.0. From [mesa-20.0.0 release note][1]: > Mesa 20.0.0 is a new development release. People who are concerned with > stability and reliability should stick with a previous release or wait for > Mesa 20.0.1. [1]: https://mesa3d.org/relnotes/20.0.0.html And I've noticed some segfaults related to mesa libraries using 20.0.0. -- 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] Linux kernel policy
On 2020-03-31 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > LTS meaning continuing maintenance so we'll still get one release for each > severe bug (even if it's a bug in a strange server motherboard). s/motherboard/& driver/ I can't type :(. > I think we can just hold on kernel 5.x.0 for the development book unless there > is a bug making it unusable. (There is already a note telling the audience to > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. -- 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] Linux kernel policy
On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > We have almost always updated the linux kernel to the "mainline" > release. We do skip intermediate releases though because of the > frequency of releases. > > For instance, today is the 90th day of the year, but there have been > about 34 releases. The first release of the year was 5.4.8. There is a > little overlap there because 5.4 is a longterm release. In any case > there have been 13 releases for 5.5 since February 1st (14 if you count > 5.6). > > I would like to propose keeping the kernel at the most recent long term > support (LTS) version for the book. Users can, of course, use whatever > version they want. > > What do you think? > >-- Bruee For 5.4 LTS, we got 21 releases in this year, and 12 releases since Feb. 1st. No significant improvement. LTS meaning continuing maintenance so we'll still get one release for each severe bug (even if it's a bug in a strange server motherboard). I think we can just hold on kernel 5.x.0 for the development book unless there is a bug making it unusable. (There is already a note telling the audience to use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. -- 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] 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
Re: [lfs-dev] Python missing from Expat's "Must be installed before" list
On 2020-03-08 09:06 +0800, Kevin Buckley via lfs-dev wrote: > The Chapter 6 Python configure instructions have a > > --with-system-expat > > option, suggesting Expat should have Python in its > > Must be installed before: > > list. > > Libffi provides a matching example. Thanks for pointing out that. Done in r11777. -- 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] Should we keep the "milestone" entity in general.ent
On 2020-03-02 10:11 +0100, Pierre Labastie via lfs-dev wrote: > Presently, this entity is 9.0, and has been last changed in July 2019. The > questions are: > - what's its use? > - if it is used, shouldn't it be changed to 9.2? > - it not, shouldn't it be removed? I think it isn't used at all and we should remove 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] Including elf/tst-protected1[ab] in glibc test failure?
On 2020-02-23 16:21 -0600, Bruce Dubbs via lfs-dev wrote:
> On 2/23/20 10:46 AM, Tadeus Prastowo via lfs-dev wrote:
> > On Sun, Feb 23, 2020 at 5:20 PM Xi Ruoyao via lfs-dev
> > wrote:
> > > We don't consider XPASS a failure. There are many XPASS in LFS packages
> > > (>20 in
> > > total, I think) and it does not make sense to document them one by one.
> > >
> > > I'd never seen a XPASS which is a "bad thing". Once a grep maintainer
> > > believed
> > > "XPASS is bad" so he made the entire test suite to FAIL if there was any
> > > XPASS.
> > > Then after a Glibc upgrading, a XPASS in grep forced us to use "-k" for
> > > grep
> > > "make check". It's stupid IMO - a test suite should not be a fragile
> > > "status
> > > change detector".
> >
> > Very interesting. So, XPASS here does not mean something that is
> > really expected to fail as in the unit test "test to open a lock with
> > the wrong key", which is expected to fail and with an XPASS really
> > means something goes wrong?
> If they expected it to do one thing and it didn't it would FAIL. If
> something normally fails, that is XFAIL. If it actually passes due to
> an update to a library or the kernel, then it would be an XPASS.
>
> Really the only thing to be concened about is a lot of FAILs. Quite a
> few packages have some small number of failures.
>
>-- Bruce
>
>
>
> > > We can add a discussion about the meaning of PASS/FAIL/XPASS/XFAIL in "4.6
> > > About
> > > the Test Suites", though.
> >
> > Seconded, and please include the case of "test to open a lock with the
> > wrong key" to define the semantics of XPASS. Thank you.
There is no such case. "test to open a lock with the wrong key" should be wrote
like:
void test_open_a_lock_with_the_wrong_key(struct test_driver *t)
{
struct lock l1, l2;
struct key k1, k2;
int ret1, ret2;
gen_key_lock_pair(, );
gen_key_lock_pair(, );
ret1 = try_open(, );
ret2 = try_open(, );
if (ret1 == FAIL_MISMATCH && ret2 == FAIL_MISMATCH)
t.pass(); /* PASS, not XFAIL */
else
t.fail(); /* FAIL, not XPASS */
}
XFAIL should never be used to indicate "this function call should return an
error". In that case you should check if the returned error code is expected.
If it's expected, this unit test should PASS, otherwise FAIL.
XFAIL is used to indicate that "we know there may be a bug but it's not fatal
and we can't fix it now (because of complications or buggy external
dependencies)".
--
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] Including elf/tst-protected1[ab] in glibc test failure?
On 2020-02-23 15:39 +0100, Tadeus Prastowo via lfs-dev wrote: > Hello, > > Quoting > http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html > > You may see some test failures. The Glibc test suite is somewhat > dependent on the host system. This is a list of the most common issues > seen for some versions of LFS: > > End quote. > > To that list, I would like to propose the inclusion of the following > failed tests: > XPASS: elf/tst-protected1a > XPASS: elf/tst-protected1b > The explanation to be included in the book is as follows: > > The tests elf/tst-protected1a and elf/tst-protected1b are known to > fail with XPASS, which is a failure due to a successful test that is > indeed expected to fail. The failures of elf/tst-protected1a and > elf/tst-protected1b with XPASS is indeed a good thing because they > have been expected to fail only with old versions of GCC and binutils > (for the details, see > https://sourceware.org/ml/libc-alpha/2015-08/msg01210.html for the > background and https://sourceware.org/ml/libc-alpha/2015-09/msg00125.html > for the conclusion). > > Thank you for considering my proposal. We don't consider XPASS a failure. There are many XPASS in LFS packages (>20 in total, I think) and it does not make sense to document them one by one. I'd never seen a XPASS which is a "bad thing". Once a grep maintainer believed "XPASS is bad" so he made the entire test suite to FAIL if there was any XPASS. Then after a Glibc upgrading, a XPASS in grep forced us to use "-k" for grep "make check". It's stupid IMO - a test suite should not be a fragile "status change detector". We can add a discussion about the meaning of PASS/FAIL/XPASS/XFAIL in "4.6 About the Test Suites", though. -- 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] A misleading `--with-sysroot' description?
On 2020-02-20 22:05 -0600, Bruce Dubbs via lfs-dev wrote: > On 2/20/20 6:57 PM, Xi Ruoyao via lfs-dev wrote: > > On 2020-02-21 01:54 +0100, Tadeus Prastowo via lfs-dev wrote: > > > Hello, > > > > > > To quote > > > http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass2.html > > > : > > > > > > --with-sysroot > > > The sysroot feature enables the linker to find shared objects which > > > are required by other shared objects explicitly included on the > > > linker's command line. Without this, some packages may not build > > > successfully on some hosts. > > > > > > End quote. > > > > > > As described in another e-mail at > > > http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-February/073506.html, > > > the `--with-sysroot' option used to configure the second binutils will > > > refer to a non-existent directory, such as > > > /LFS-tools/x86_64-pc-linux-gnu/sys-root/. In other words, it cannot > > > be the case that the linker (ld) will "find shared objects which are > > > required by other shared objects explicitly included on the linker's > > > command line" in the non-existent directory. While it is true that > > > "without this, some packages may not build successfully on some hosts" > > > (e.g., the first build of Perl), the description of the > > > `--with-sysroot' can be improved as follows: > > > > > > This option will prevent the linker from looking in the default places > > > in the build system (e.g., by reading the file /etc/ld.so.conf) by > > > forcing the linker to look only in places within the non-existent > > > default sysroot directory /tools/$LFS_TGT/sys-root. If this option is > > > not given and the linker reads some working ld.so.conf of the build > > > system, the linker will produce objects that are linked to the build > > > system's library, not to the libraries built within the /tools > > > directory, which defeats the effort of having a clean build. > > > > > > What do you think? Thanks. > > > > I agree. This also confused me when I was doing the Chinese translation. > > I think we can improve the wording here, bu tnote that the linker > actually looks at ld.so.cache, not ld.so.conf. Only the ldconfig > command looks at ld.so.conf. No. The linker (/usr/bin/ld) looks at ld.so.conf, but the dynamic linker (/lib/ld-linux-x86-64.so.2) looks at ld.so.cache. > I'll use the above to try to reword the explanation of the > --with-sysroot option. > >-- Bruce > -- 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] A misleading `--with-sysroot' description?
On 2020-02-21 01:54 +0100, Tadeus Prastowo via lfs-dev wrote: > Hello, > > To quote > http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass2.html > : > > --with-sysroot > The sysroot feature enables the linker to find shared objects which > are required by other shared objects explicitly included on the > linker's command line. Without this, some packages may not build > successfully on some hosts. > > End quote. > > As described in another e-mail at > http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-February/073506.html, > the `--with-sysroot' option used to configure the second binutils will > refer to a non-existent directory, such as > /LFS-tools/x86_64-pc-linux-gnu/sys-root/. In other words, it cannot > be the case that the linker (ld) will "find shared objects which are > required by other shared objects explicitly included on the linker's > command line" in the non-existent directory. While it is true that > "without this, some packages may not build successfully on some hosts" > (e.g., the first build of Perl), the description of the > `--with-sysroot' can be improved as follows: > > This option will prevent the linker from looking in the default places > in the build system (e.g., by reading the file /etc/ld.so.conf) by > forcing the linker to look only in places within the non-existent > default sysroot directory /tools/$LFS_TGT/sys-root. If this option is > not given and the linker reads some working ld.so.conf of the build > system, the linker will produce objects that are linked to the build > system's library, not to the libraries built within the /tools > directory, which defeats the effort of having a clean build. > > What do you think? Thanks. I agree. This also confused me when I was doing the Chinese translation. -- 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] New package issues
BTW: which address in lfs-dev@{lists.,}linuxfromscratch.org is correct?
On 2020-02-01 16:50 -0600, Bruce Dubbs via lfs-dev wrote:
> I've been able to work around the problem with:
>
> sed -e '1161 s|^|//|' \
> -i libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
>
> and it is probably all right since it is just an internal assertion check.
According to
https://github.com/llvm/llvm-project/commit/947f9692440836dcb8d88b74b69dd379d85974ce
it's correct. Please disregard my previous email.
--
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] New package issues
On 2020-02-01 16:50 -0600, Bruce Dubbs via lfs-dev wrote: > I am building a fresh LFS with the latest glibc and binutils and ran > into a problem when building gcc-pass2 in Chapter 5. > > linux-5.5.1 > glibc-2.31 > binutils-2.34 > > What the error looks like is somewhat complex and it looks like (long > lines so there is wrapping in the email): > > In file included from > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1 > 93: > ../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:339:72: > error: narrowing conversion of '-1' from 'int' to 'long unsigned int' > [-Wnarrowing] >339 | typedef char IMPL_PASTE(assertion_failed_##_, > line)[2*(int)(pred)-1] >| > ^ > ../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:333:30: > note: in expansion of macro 'IMPL_COMPILER_ASSERT' >333 | #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) > > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:15 > 11:3: > note: in expansion of macro 'COMPILER_CHECK' > 1511 | COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) > == \ > > ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1 > 161:1: > note: in expansion of macro 'CHECK_SIZE_AND_OFFSET' > 1161 | CHECK_SIZE_AND_OFFSET(ipc_perm, mode); > > > The command line includes -Werror even if I specify --disable-werror in > configure. > > I've been able to work around the problem with: > > sed -e '1161 s|^|//|' \ > -i libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > > and it is probably all right since it is just an internal assertion check. I don't think it's right. It's a "static assertion": char _static_assert_233[something_should_be_true() ? 1 : -1]; It makes the compilation to fail if something is out of the developers's assumption. I think GCC needs some fixes for Glibc-2.31. I'll search through GCC trunk. -- 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] Adding zstd
On 2020-01-12 12:08 -0600, Bruce Dubbs via lfs-dev wrote: > Note that tar needs to be rebuilt after zstd to recognize zstd > compressed tarballs. That seems not true... -- 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] Adding zstd
Zstd is installing libzstd.a and (I think) we should remove it. And, should we move libzstd.so.* to /lib just like libz.so.*, libbz2.so.* and liblzma.so.*? -- 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] libcap-2.29: why use prefix=/usr, and useless sed
On 2020-01-03 09:42 -0800, Joel Bion via lfs-dev wrote:
> On 2020-01-03 07:40, Bruce Dubbs via lfs-dev wrote:
> > On 1/3/20 3:48 AM, Pierre Labastie via lfs-dev wrote:
> > > Le 02/01/2020 à 23:53, Bruce Dubbs via lfs-dev a écrit :
> > > > On 1/2/20 3:26 PM, Pierre Labastie via lfs-dev wrote:
> > > > > Second, use prefix=/usr for Make install, then move the shared
> > > > > library to
> > > > > /lib. But actually, if we do not pass prefix, the shared library is
> > > > > directly
> > > > > installed in /lib (note, we do need to pass lib=lib, but now
> > > > > RAISE_SETFCAP=no
> > > > > is the default). The only difference is that some binaries are
> > > > > installed in
> > > > > /usr/sbin if we pass prefix=/usr and they are installed in /sbin if
> > > > > not. Not a
> > > > > big deal, we do not use them anyway...
> > > > >
> > > > > I'll make a test build with the sed above and just "make lib=lib
> > > > > install"
> > > > > (without touching the library), and change the book if everything is
> > > > > OK.
> > > >
> > > > OK, thanks.
>
> I'd like to offer an opinion as to why things should stay as they are in
> the making of libcap.
>
> It's this:
>
> 1) Mechanisms with guaranteed results are more robust than depending on
> current defaults, that a package could change at any time.
>
> It is true - today - that libcap puts things in /lib. Therefore - with
> today's behavior - installing them in /usr/lib and then moving them to
> /lib seems kind of odd.
>
> However, the current method LFS uses is guaranteed to still work even if
> a future chooses to start putting things in /usr/local by default, or
> any other place.
>
> Since the current method incurs no real extra cost, and is more robust,
> I'd ask that we consider leaving things as they are - and indeed, making
> sure that no other packages in LFS are depending on the 'default'
> location of installation of things, when a simple configuration
> parameter will put them in a known location.
I strongly disagree this kind of argument.
There are thousands of parameters in "configure", "cmake" or "meson". For 90%
of them we are using the default. Could we make all "configure" commands to be
./configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --
libexecdir=/usr/libexec --sysconfdir=/etc --localstatedir=/var --
runstatedir=/var/run --libdir=/usr/lib --includedir=/usr/include --
datarootdir=/usr/share --infodir=/usr/share/info --localedir=/usr/share/locale
--mandir=/usr/share/man --{doc,html,dvi,pdf,ps}dir=/usr/share/doc/foo-1.2.3 --
with-{a,b,c,d,e,f,g}=yes --with-{h,i,j,k,l,m,n}=no
just because we can confort ourselves that it's thought to be "more robust"?
Then what if the upstream decides to use cmake or meson?
--
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] Distro Comparison
On 2019-12-16 00:40 -0600, Bruce Dubbs via lfs-dev wrote: > On 12/16/19 12:16 AM, Xi Ruoyao via lfs-dev wrote: > > > Considering SBU value, should we add --enable-checking=release into > > GCC > > configure command? Most distributions are using it and I think > > it's > > safe with GCC release tarballs (instead of svn checkout). > > According to https://gcc.gnu.org/install/configure.html, release is > the > default for gcc releases. It doesn't appear to be needed for us. > >-- Bruce Oh, specifying --enable-checking=release only affects stage1. I use 3- stage bootstrapping building GCC but LFS/BLFS does not. Sorry for the noise. -- 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] Distro Comparison
On 2019-12-15日的 23:54 -0600，Bruce Dubbs via lfs-dev wrote:
> On 12/15/19 7:06 PM, Ken Moffat via lfs-dev wrote:
> > On Sun, Dec 15, 2019 at 12:30:52PM -0600, Bruce Dubbs via lfs-dev
> > wrote:
> > > https://www.phoronix.com/scan.php?page=article=10980xe-intel-linux
> > >
> > > I find the benchmarks interesting. On page 5 is the time for
> > > kernel
> > > comparison. On my Haswell I get for linux-5.4.2:
> > >
> > > $ time make defconfig
> > > real0m2.883s
> > >
> > > $ time make
> > > real15m28.691s
> > >
> > > And after 'make mrproper; make defconfig'
> > >
> > > $ time make -j12
> > > real2m24.326s
> > >
> > > Clearly it's time for me to consider upgrading my development
> > > system, but
> > > I'm waiting to see what Intel's 10nm processors can do and what
> > > they will
> > > cost. My current SBU time is 101s and some of the larger
> > > packages like
> > > libreoffice, thunderbird, qt, qtwebengine. etc are a bit tedious.
> > >
> >
> > I don't ever make defconfig (apart from my laptop, my configs are
> > adequately smaller although some unwanted things invariably get
> > pulled in). But I see that on my i7 haswell (DDR3 1600!) the SBU
> > is
> > around 101s - latest binutils adds a second or two - and on my
> > Picasso (DDR4 3000 but with binutils-2.32) the latest build was
> > also
> > 101s.
> >
> > For kernel compiles, make -j{N+1} is the old recommendation, or
> > from
> > people like Greg K-H make -j{Nx2}. Unlike C++ and rust the kernel
> > doesn't use a lot of RAM when compiling.
> >
> > But I don't see that I'll buy intel again in the foreseeable
> > future.
> >
> > > On the other hand on page 6, Systemd Total Boot Time
> > >
> > > The best time was about 25 seconds. On my Haswell, my LFS System
> > > V boot
> > > time is 8 seconds.
> > >
> > >-- Bruce
> >
> > My haswell often spends several seconds in boot with things like
> > unbound (for me, that is used on all systems, not as a server
> > package). But I haven't timed a boot recently. For systemd
> > desktops, the time will include both X (or Wayland) and the
> > display manager.
>
> For SysV the boot times are in /var/log/boot.log.
>
>-- Bruce
Considering SBU value, should we add --enable-checking=release into GCC
configure command? Most distributions are using it and I think it's
safe with GCC release tarballs (instead of svn checkout).
--
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] Debian 10.2 install changes LFS kernel entry in grub.cfg
On 2019-12-09 08:43 +0900, Akira Urushibata via lfs-dev wrote: > Recently I installed Debian 10.2 on a computer with both LFS and > older > Debian versions. The installer automatically produced a new grub.cfg > in which LFS is listed as "unknown Linux distribution." To my great > surprise the listed kernel was changed to the new kernel that comes > with Debian 10.2. This had never happened in the past. I haven't > checked but I believe that grub-mkconfig is responsible for this. > > The Debian kernel does not work with LFS because CONFIG_DEVTMPFS > (maintain a devtmpfs filesystem to mount at /dev) is not set. > There may be other issues. LFS may boot, but you may not have enough > functionality to edit /boot/grub/grub.cfg . > > I don't know whether there should be some words of caution in the > Book > on installing other systems on the same computer after LFS. This > issue is not directly related to building LFS so probably it has no > place in the Book. On the other hand, many of us run multi-boot > systems which means many people are going to go through this. There are these words. In Chap 8 Sect 4: > Caution > There is a command, grub-mkconfig, that can write a configuration > file automatically. It uses a set of scripts in /etc/grub.d/ and will > destroy any customizations that you make. These scripts are designed > primarily for non-source distributions and are not recommended for > LFS. If you install a commercial Linux distribution, there is a good > chance that this program will be run. Be sure to back up your > grub.cfg file. I'm installing Arch along with LFS on my new laptop. I added GRUB_OS_PROBER_SKIP_LIST into Arch /etc/default/grub to tell grub- mkconfig not to probe my LFS system (and generate unusable LFS entries). Then I added LFS entry manually into /boot/grub/custom.cfg. The grub.cfg generated by grub-mkconfig will load this file and show the entry. -- 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] Kernel 5.3.1 uses rsync
On 2019-09-23 10:30 -0500, Bruce Dubbs via lfs-dev wrote: > On 9/23/19 9:24 AM, John Burrell via lfs-dev wrote: > > I haven't noticed this before but linux-5.3.1 uses rsync to transfer > > the files in the command > > > > make INSTALL_HDR_PATH=dest headers_install > > > > This is okay in chap. 5 if rsync is on the host but it doesn't work in > > chap. 6 as rsync is not in /tools. > > I see that. I suppose we could try to build rsync early in Chapter 5 only. > > ./configure --disable-acl-support \ > --disable-xattr-support \ > --with-included-popt > make > cp rsync /tools/bin > > $ ldd ./rsync > linux-vdso.so.1 (0x7fffaa7c2000) > libc.so.6 => /lib/libc.so.6 (0x7ff50ffc3000) > /lib64/ld-linux-x86-64.so.2 (0x7ff5101b6000) > > This is the first time I've looked at the 5.3 kernel. Not tested other > than the above thru make. > >-- Bruce I propose: make headers mkdir dest cp -rv usr/include dest/include find dest/include \( -name .install -o -name ..install.cmd \) -delete cp -rv dest/include/* /usr/include I don't like a rsync in LFS (I never use this thing :). -- 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] Kernel 5.3.1 uses rsync
On 2019-09-23 15:24 +0100, John Burrell via lfs-dev wrote: > I haven't noticed this before but linux-5.3.1 uses rsync to transfer > the files in the command > > make INSTALL_HDR_PATH=dest headers_install > > This is okay in chap. 5 if rsync is on the host but it doesn't work in > chap. 6 as rsync is not in /tools. > > quel problème > > jb. The change was made in 59b2bd05f5f4. According to its commit log we can change to use "make headers" insteadly and then copy the headers directly from "usr" directory. -- 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] kbd: the note about Belarusian keymap seems outdated
On 2019-09-07 11:00 +0800, Xi Ruoyao via lfs-dev wrote: > It's said: > > > For some languages (e.g., Belarusian) the Kbd package doesn't provide a > > useful > > keymap where the stock “by” keymap assumes the ISO-8859-5 encoding, and the > > CP1251 keymap is normally used. Users of such languages have to download > > working keymaps separately. > > But now there is a CP1251 keymap for Belarusian provided in kbd-2.2.0 tarball > (kbd-2.2.0/data/keymaps/i386/qwerty/by-cp1251.map). > > I think the note should be revised. The note is added with kbd-1.12. In kbd-1.12 tarball there is only by.map which is ISO-8859-1. So the note is really outdated. I'll remove it if nobody objects. -- 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] kbd: the note about Belarusian keymap seems outdated
It's said: > For some languages (e.g., Belarusian) the Kbd package doesn't provide a useful > keymap where the stock “by” keymap assumes the ISO-8859-5 encoding, and the > CP1251 keymap is normally used. Users of such languages have to download > working keymaps separately. But now there is a CP1251 keymap for Belarusian provided in kbd-2.2.0 tarball (kbd-2.2.0/data/keymaps/i386/qwerty/by-cp1251.map). I think the note should be revised. -- 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] LFS and BLFS Version 9.0 are released
On 2019-09-01 12:54 -0500, Bruce Dubbs via lfs-dev wrote: > The Linux From Scratch community is pleased to announce the release of > LFS Version 9.0, LFS Version 9.0 (systemd), BLFS Version 9.0, and BLFS > Version 9.0 (systemd). > > This release is a major update to both LFS and BLFS. > > The LFS release includes updates to glibc-2.30, and gcc-9.2.0. A total > of 33 packages have been updated. Changes to text have been made > throughout the book. The Linux kernel has also been updated to version > 5.2.8. > > The BLFS version includes approximately 1000 packages beyond the base > Linux From Scratch Version 9.0 book. This release has over 850 updates > from the previous version in addition to numerous text and formatting > changes. > > The System V version of the book now has added Gnome as an additional > desktop environment in addition to the previous KDE/plasma, xfce, and > lxde environments. > > Thanks for this release goes to many contributors. Notably: > > Douglas Reno > DJ Lucas > Ken Moffat > Thomas Trepl > Pierre Labastie > Tim Tassonis > Xi Ruoyao > > You can read the books online[0]-[3], or download[4]-[7] to read locally. > > Please direct any comments about this release to the LFS development > team at lfs-...@linuxfromscratch.org or blfs-...@linuxfromscratch.org. > Registration for the mailing lists is required to avoid junk email. > >-- Bruce Dubbs > LFS > > [0] http://www.linuxfromscratch.org/lfs/view/9.0/ > [1] http://www.linuxfromscratch.org/blfs/view/9.0/ > [2] http://www.linuxfromscratch.org/lfs/view/9.0-systemd/ > [3] http://www.linuxfromscratch.org/blfs/view/9.0-systemd/ > > [4] http://www.linuxfromscratch.org/lfs/downloads/9.0/ > [5] http://www.linuxfromscratch.org/blfs/downloads/9.0/ > [6] http://www.linuxfromscratch.org/lfs/downloads/9.0-systemd/ > [7] http://www.linuxfromscratch.org/blfs/downloads/9.0-systemd/ My LFS Chinese translation is available at my personal website: https://bf.mengyan1223.wang/lfs/zh_CN/. I intend to migrate it to linuxfromscratch.org.cn in this semester. I've purchased this domain since 2018 but I just didn't have time to set it up. -- 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] Weird markup in meson
On 2019-08-28 11:39 +0200， Julien Lepiller via lfs-dev wrote: > Hi, > > In meson from chapter 6, I see: … via an environment variable, > NINJAJOBS. For example, setting … > > But that's not a command, is it? :) There is a comment saying it's intentional to make "For example" bold. -- 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] gcc-9.2.0
On 2019-08-16 16:25 +0200, Riccardo Corsi via lfs-dev wrote: > Hello, I have a question about GCC 9.2.0 > Is there a new option for ISL ? > I have in my configure (build of LFS 9.0-rc1) of GCC: > > ../configure --prefix=/usr\ > > --enable-languages=c,c++ \ > > --disable-multilib \ > > --disable-bootstrap \ > > --with-system-zlib > > checking for isl 0.15 or later... no > required isl version is 0.15 or later > *** This configuration is not supported in the following subdirectories: > zlib gnattools gotools target-libada target-libhsail-rt target-libphobos > target-zlib target-libbacktrace target-libgfortran target-libgo target-libffi > target-libobjc target-liboffloadmic > (Any other directories should still work fine.) > ... > > Have you seen this? I'l double check my /mnt/lfs instance... That's normal because ISL is not a part of LFS, and it's not a hard dependency of GCC. You can continue to build GCC unless you want to use graphite optimization (unlikely). -- 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] Things could get much worse for bzip2
On 2019-06-27 18:57 +0200, Thomas Trepl via lfs-dev wrote: > Am Donnerstag, den 27.06.2019, 05:24 -0400 schrieb Marty Jack via lfs- > dev: > > Reading the new homepage, it seems this is the gentleman who rewrote librsvg > > in Rust and plans to do the same for bzip2. If he cannot be dissuaded, this > > will have a disastrous effect on Chapter 5. > Right, unfortunatly. > > I'm still using the last version of non-rust-librsvg. Up to now, it > seems to work fine. Of course, bugfixes are not there. > > (in my undergraduated mind i never understood whats so cool in rust > which justifies that monster of compiler infrastructure, and in this > case, such a monster building a relativly small tool) I can't understand this, too. I can accept a rust-librsvg (because it's said rust is "designed for web broswer engine" and SVG is something related to web engine). But why should bzip2 be rewrote in rust? I think I'll have to fork a non-rust-bzip2. -- 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] bzip2 has a new maintainer and a repository now
On 2019-06-25 12:52 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/25/19 11:57 AM, Ryan Marsaw via lfs-dev wrote: > > On Sun, 23 Jun 2019, Brendan L via lfs-dev wrote: > > > > > Blog about the change in maintainership: > > > https://people.gnome.org/~federico/blog/maintaining-bzip2.html > > > > > > Here is another blog entry about the coming release: > > > https://people.gnome.org/~federico/blog/preparing-the-bzip2-107-release.html > > > > > > > > > > > > There is a fix for a new security issue. Also the build system is now > > > meson and cmake. > > > -- > > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > > FAQ: http://www.linuxfromscratch.org/faq/ > > > Unsubscribe: See the above information page > > > > I was able to complete a LFS build using the latest git snapshot of > > bzip2 (still no release tarball yet). > > > > Here are my findings: > > > > Chapter 5 (Constructing a Temporary System) > > > > 1) Ninja and Meson will now need to be installed in Chapter 5, just > > after the Python 3 package. > > > > For ninja: > > python3 configure.py --bootstrap > > install -v -m 0755 ninja /tools/bin > > > > For meson: > > python3 setup.py build > > python3 setup.py install --root=dest > > cp -v -R dest/tools/* /tools > > > > 2) Python 3 will need to be built with the switch "--with-ensurepip=yes" to > > satisfy the installation of meson, which means that zlib and libffi will > > need to be installed prior to Python 3, with "--with-system-ffi" > > switch added to Python 3 configuration. I think we can skip setuptools/pip things and use meson without installing it. There is a meson.py in meson source tarball. We should be able to run meson with "python3 /source/meson-/meson.py". I'll try this approach tomorrow. -- 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] GCC ERROR
On 2019-05-20 14:42 +0200, emiliocabrera via lfs-dev wrote: > Hi. I´m at 5.5.1 Installation of Cross GCC, I´m building the LFS V8.4 > on > a VirtualBox machine with Debian x86_x64 installed. I get this error: > > Configuring stage 2 in ./intl Why should a cross compiler bootstrap itself? > configure: creating cache ./config.cache > checking whether make sets $(MAKE)... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether NLS is requested... no > checking for msgfmt... no > checking for gmsgfmt... : > checking for xgettext... no > checking for msgmerge... no > checking for x86_64-pc-linux-gnu-gcc... Why should it be x86_64-pc-linux-gnu? I think you forgot --target=$LFS_TGT in the configure command, or didn't set the environment variable LFS_TGT. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Am I supposed to set some CFLAGS to build LFS ?
On 2019-05-12 05:24 +0100, Ken Moffat via lfs-dev wrote: > As people probably know, I usually set my own CFLAGS when building > LFS (at a minimum, -O2 to get rid of most debug symbols). Me too. > But I'm now trying to compare the build times and the size of the > executables for "I did it my way" against using the default CFLAGS > from the individual packages (or from BLFS, or using releease builds > for cmake and meson). > > Got through chapter 5 ok, time was not a lot greater but the space > used by /tools was a lot bigger (2.4 GB instead of 851MB). But in > chapter 6 glibc was not happy: > > # error "glibc cannot be compiled without optimization" > > Looking on google, and trying to follow a link to the FAQ > specifically for this (apparently failed, but left me at hte FAQ) > all I can find is the old advice from Seth: if you use CFLAGS and > the build fails, people will suggest you try without those CFLAGS. > > Fine, and I remember suggestions to use -O3 for glibc from Greg > Schafer. So, I've added CFLAGS='-O2' for glibc if my own CFLAGS are > not set (and I had a similar fix which became ineffective when I > reworked how I set/pass my CFLAGS, at that time it was labelled as > being needed for at least x86_32). > > But unless I'm looking in the wrong place, I can't see any CFLAGS in > the book ? So, how do you all build glibc in chroot ? In autotools configure script, if CFLAGS is not set, the script defaults to use "-O2 -g" or something the package author set. However, if it is set (for some packages, *even if set to nothing*, i. e. CFLAGS=""), the script will throw away the default and use your setting. That's different from cmake or meson. Beside the stupid libtool, I also dislike this "feature" of autotools. -- 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] LFS-8.4 systemd issue with util-linux
On 2019-05-10 15:35 -0400, Joe Locash via lfs-dev wrote:
> In section 6.72 when building systemd, symlinks are created to
> /tools/lib/lib{blkid,mount,uuid}*. When util-linux is rebuilt in 6.75 it is
> built with --disable-static. In section 5.34, util-linux is not built with
> that flag so .a static libraries are installed for those. Those symlinks don't
> get removed and creep into BLFS and can cause issues, notably with the serf
> package. --disable-static should also be used in 5.34 or the .a symlinks
> removed in the cleaning up section.
Fixed in r11599. Thanks for the report.
If this issue is in 8.4 release we'll need an errata...
--
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] [RFC] Move iana-etc before GCC for GCC test suite
On 2019-05-07 14:14 -0500, Bruce Dubbs via lfs-dev wrote: > On 5/7/19 12:44 PM, Xi Ruoyao via lfs-dev wrote: > > On 2019-05-07 11:46 -0500, Bruce Dubbs via lfs-dev wrote: > > > On 5/7/19 6:07 AM, Xi Ruoyao via lfs-dev wrote: > > > > Hi folks, > > > > > > > > I just updated the status of GCC test suite in r11593. I noticed two > > > > failures > > > > because the lack of /etc/hosts and iana-etc. They can be resolved by > > > > using > > > > the > > > > minimal hosts file from Perl page, and installing iana-etc before GCC. > > > > > > > > The edited book is at > > > > http://www.linuxfromscratch.org/~xry111/LFS-BOOK-rfc/. > > > > > > I saw those updates. Thanks. > > > > > > If you want to dig into gcc, take a look at the 100 gcc errors when > > > valgrind and gdb are installed. Most seem to be related, but I didn't > > > want to try to figure them out. Upstream knows about them as I found > > > them in the test results page. > > > > I just ignore all failures of "guality" tests. > > > > > If test failures are due to the test environment or bugs in the tests > > > themselves, I generally don't think is is worth our time to try to > > > figure out fixes. > > > > Only because I was using some CFLAGS/CXXFLAGS, I spent some time to make > > sure > > these flags didn't cause the failures. I think it's OK to document these > > failures in the book and let the readers to ignore them. So let's keep the > > book > > like now. > > I agree. > > > But, just curious, why did we move shadow for several gcc tests? > > From the change log last August: > > "Move shadow to before gcc so the gcc tests can > use su to run as a non-privileged user." I mean we moved shadow to run gcc testsuite as a non-privileged user, only in order to fix several failures in libstdc++fs tests... -- 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] [RFC] Move iana-etc before GCC for GCC test suite
On 2019-05-07 11:46 -0500, Bruce Dubbs via lfs-dev wrote: > On 5/7/19 6:07 AM, Xi Ruoyao via lfs-dev wrote: > > Hi folks, > > > > I just updated the status of GCC test suite in r11593. I noticed two > > failures > > because the lack of /etc/hosts and iana-etc. They can be resolved by using > > the > > minimal hosts file from Perl page, and installing iana-etc before GCC. > > > > The edited book is at http://www.linuxfromscratch.org/~xry111/LFS-BOOK-rfc/. > > I saw those updates. Thanks. > > If you want to dig into gcc, take a look at the 100 gcc errors when > valgrind and gdb are installed. Most seem to be related, but I didn't > want to try to figure them out. Upstream knows about them as I found > them in the test results page. I just ignore all failures of "guality" tests. > If test failures are due to the test environment or bugs in the tests > themselves, I generally don't think is is worth our time to try to > figure out fixes. Only because I was using some CFLAGS/CXXFLAGS, I spent some time to make sure these flags didn't cause the failures. I think it's OK to document these failures in the book and let the readers to ignore them. So let's keep the book like now. But, just curious, why did we move shadow for several gcc tests? -- 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] [RFC] Move iana-etc before GCC for GCC test suite
Hi folks, I just updated the status of GCC test suite in r11593. I noticed two failures because the lack of /etc/hosts and iana-etc. They can be resolved by using the minimal hosts file from Perl page, and installing iana-etc before GCC. The edited book is at http://www.linuxfromscratch.org/~xry111/LFS-BOOK-rfc/. The diff is attached. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University diff -Nuar trunk/BOOK/chapter06/chapter06.xml BOOK-rfc/chapter06/chapter06.xml --- trunk/BOOK/chapter06/chapter06.xml 2019-03-25 01:16:40.477261055 +0800 +++ BOOK-rfc/chapter06/chapter06.xml 2019-05-07 18:53:59.406285861 +0800 @@ -31,6 +31,7 @@ http://www.w3.org/2001/XInclude; href="mpfr.xml"/> http://www.w3.org/2001/XInclude; href="mpc.xml"/> http://www.w3.org/2001/XInclude; href="shadow.xml"/> + http://www.w3.org/2001/XInclude; href="iana-etc.xml"/> http://www.w3.org/2001/XInclude; href="gcc.xml"/> http://www.w3.org/2001/XInclude; href="bzip2.xml"/> http://www.w3.org/2001/XInclude; href="pkgconfig.xml"/> @@ -40,7 +41,6 @@ http://www.w3.org/2001/XInclude; href="libcap.xml"/> http://www.w3.org/2001/XInclude; href="sed.xml"/> http://www.w3.org/2001/XInclude; href="psmisc.xml"/> - http://www.w3.org/2001/XInclude; href="iana-etc.xml"/> http://www.w3.org/2001/XInclude; href="bison.xml"/> http://www.w3.org/2001/XInclude; href="flex.xml"/> http://www.w3.org/2001/XInclude; href="grep.xml"/> diff -Nuar trunk/BOOK/chapter06/gcc.xml BOOK-rfc/chapter06/gcc.xml --- trunk/BOOK/chapter06/gcc.xml 2019-05-07 18:47:47.647160270 +0800 +++ BOOK-rfc/chapter06/gcc.xml 2019-05-07 18:58:33.038936328 +0800 @@ -114,6 +114,12 @@ ulimit -s 32768 +Create a basic /etc/hosts file to be +referenced in GCC test suite, as well as Perl's configuration files and +optional test suite: + +echo "127.0.0.1 localhost $(hostname)" /etc/hosts + Test the results as a non-privileged user, but do not stop at errors: chown -Rv nobody . @@ -133,10 +139,6 @@ Six tests related to get_time are known to fail. These are apparantly related to the en_HK locale. -Two tests named lookup.cc and reverse.cc in experimental/net -are known to fail in LFS chroot environment because they require -/etc/hosts and iana-etc. - Two tests named pr57193.c and pr90178.c are known to fail. A few unexpected failures cannot always be avoided. The GCC developers diff -Nuar trunk/BOOK/chapter06/perl.xml BOOK-rfc/chapter06/perl.xml --- trunk/BOOK/chapter06/perl.xml 2019-05-03 04:50:49.836579449 +0800 +++ BOOK-rfc/chapter06/perl.xml 2019-05-07 18:55:35.886047753 +0800 @@ -41,12 +41,6 @@ Installation of Perl -First create a basic /etc/hosts file to be -referenced in one of Perl's configuration files as well as the optional -test suite: - -echo "127.0.0.1 localhost $(hostname)" /etc/hosts - This version of Perl now builds the Compress::Raw::Zlib and Compress::Raw::BZip2 modules. By default Perl will use an internal copy of the sources for the build. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] New test failure in Glibc: misc/check-installed-headers-c
On 2019-05-02 12:48 -0500, Bruce Dubbs via lfs-dev wrote: > On 5/2/19 12:15 PM, Xi Ruoyao via lfs-dev wrote: > > The test suite log says: > > > > *** Obsolete types detected: > > /usr/include/linux/sysctl.h:KERN_PANIC_PRINT=78, /* ulong: bitmask to > > print > > system info on panic */ > > > > So this test failure seems because of changes in Linux API headers. > > > > Should we note this in the book? > > I think we should hold off. The kernel changes so much that the API > could change back to allow the test to pass. We should re-examine this > in early August as a part of the next cycle release preparation. It will be fixed in Glibc-2.30: http://sourceware.org/git/?p=glibc.git;a=commit;h=711a322a235d4c8177713f11aa59156603b94aeb Let's see if it would be released before LFS-8.5. -- 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] New test failure in Glibc: misc/check-installed-headers-c
The test suite log says: *** Obsolete types detected: /usr/include/linux/sysctl.h:KERN_PANIC_PRINT=78, /* ulong: bitmask to print system info on panic */ So this test failure seems because of changes in Linux API headers. Should we note this in the book? -- 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] Eudev installs two PkgConfig files in seperate locations?
On 2019-04-30 13:46 +0800, Kevin Buckley via lfs-dev wrote: > On Sun, 21 Apr 2019 at 12:08, Xi Ruoyao via lfs-dev > wrote: > > > > by virtue of pointing to the /lib/udev, which is arch-specific, > > > > It's not. /lib/udev only contains udev scripts and some executable > > helpers for > > udevd. There are no libraries in it. > > > > We can not have two udevd instances for x86_64 and i686, so udevd > > is not arch- > > specific. Run `ps -e | grep udevd` and you won't see something > > like "udevd-32" > > or "udevd-64". > > I think you may have misunderstood, or maybe I have. > > I do take your point about the udev subdirectory of /lib not > containing any libs, however as I see things, > > /lib > > and hence, subdirectories of it, is arch-specfic, as it what > would be /lib64 on a system that had a mix of arches and > hence various /lib-s . This is just your false assumption. You may believe everything in /lib should have a corresponding one in /lib64. That's incorrect. For example, "/lib64/modules" is totally unreasonable. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Our perl builds are not hardened
On 2019-04-23 04:09 +0100, Ken Moffat via lfs-dev wrote: > On Thu, Apr 18, 2019 at 10:59:04PM +0100, Ken Moffat wrote: > > I was looking through my logs to identify which packages do not use > > my CFLAGS, CXXFLAGS (thinking about trying LTO at some point) and > > reading the voluminous output from perl's Configure I noticed: > > > > Guessing which symbols your C compiler and preprocessor define... > > You seem not to have gcc 4.* or later, not adding -D_FORTIFY_SOURCE. > > > > That is because 5.28.1 has the following: > > > > case "$gccversion" in > > [4567].*) case "$optimize$ccflags" in > > > > Using > > sed -i 's/^\(\[4567\)/\18/' Configure > > gives me > > > > Guessing which symbols your C compiler and preprocessor define... > > Adding -D_FORTIFY_SOURCE=2 to ccflags... > > > > ĸen > > This still applies to 5.28.2. I guess that distros such as fedora > and Arch have not reported this upstream because they *always* force > their own CFLAGS which include a -DFORTIFY_SOURCE setting. I've reported this (several months ago): https://rt.perl.org/Public/Bug/Display.html?id=133490 And they've fixed it in dev branch. They just didn't backport this into 5.28.x. -- 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
