On Wed, Jan 29, 2020 at 07:00:18PM -0700, Alan Feuerbacher via blfs-support wrote: > I'm building the development version of systemd. > > After updating various programs listed in the Changelogs for LFS and BLFS, I > left linux-5.5 for last. I had upgraded to linux-5.4.13 a few days ago, > without trouble. Keeping in mind that glibc-2.30 depends on the linux > headers, as stated in the LFS book:
[snip] > > I did that sanitizing with linux-5.5, and then built the full linux-5.5. > Unlike earlier builds, the build process asked a bunch of questions about > "makemenu" options, most of which I accepted the default for. Then I > modified the configuration file of the boot manager I use, rEFInd, to > account for the updated linux version. Unfortunately I missed changing one > line that specifies loading the initrd file, which stayed at the one for > linux-5.4.13. I rebooted the system, and everything seemed to be ok. At > least, until I tried to compile Fluxbox. > > That complained that a couple of pieces of libstdc++ were missing. After > some research, I decided to recompile glibc, which required redoing the > Linux API Headers stuff first. Then "make" for glibc went into an endless > loop after 3-4 minutes, so I eventually Control-C'd out of it. I repeated > this process several times with the same result. Here's the repeating part > of the loop: > > ########### > python3 -B ../scripts/gen-as-const.py --cc="gcc > -ffile-prefix-map=/tools=/usr -std=gnu11 -fgnu89-inline -g -O2 -Wall > -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math > -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition > -fmath-errno -ftls-model=initial-exec -I../include > -I/sources/glibc-2.30/build/nptl -I/sources/glibc-2.30/build > -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 > -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 > -I../sysdeps/x86/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 > -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include > -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread > -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv > -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix > -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch > -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu > -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 > -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include > -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 > -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 > -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. > -I../libio -I. -nostdinc -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed -isystem /usr/include > -D_LIBC_REENTRANT -include /sources/glibc-2.30/build/libc-modules.h > -DMODULE_NAME=libc -include ../include/libc-symbols.h > -DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS \ > -MD -MP -MF > /sources/glibc-2.30/build/pthread-pi-defines.h.dT \ > -MT '/sources/glibc-2.30/build/pthread-pi-defines.h.d > /sources/glibc-2.30/build/pthread-pi-defines.h'" \ > pthread-pi-defines.sym > > /sources/glibc-2.30/build/pthread-pi-defines.hT > sed -e 's@ /sources/glibc-2\.30/build/@ $(common-objpfx)@g' -e > 's@^/sources/glibc-2\.30/build/@$(common-objpfx)@g' -e 's@ *\.\.\/\([^ > \]*\)@ $(..)\1@g' -e 's@^\.\.\/\([^ \]*\)@$(..)\1@g' \ > /sources/glibc-2.30/build/pthread-pi-defines.h.dT > > /sources/glibc-2.30/build/pthread-pi-defines.h.dT2 > rm -f /sources/glibc-2.30/build/pthread-pi-defines.h.dT > mv -f /sources/glibc-2.30/build/pthread-pi-defines.h.dT2 > /sources/glibc-2.30/build/pthread-pi-defines.h.d > mv -f /sources/glibc-2.30/build/pthread-pi-defines.hT > /sources/glibc-2.30/build/pthread-pi-defines.h > python3 -B ../scripts/gen-as-const.py --cc="gcc > -ffile-prefix-map=/tools=/usr -std=gnu11 -fgnu89-inline -g -O2 -Wall > -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math > -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition > -fmath-errno -ftls-model=initial-exec -I../include > -I/sources/glibc-2.30/build/nptl -I/sources/glibc-2.30/build > -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 > -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 > -I../sysdeps/x86/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 > -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include > -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread > -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv > -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix > -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch > -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu > -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 > -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include > -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 > -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 > -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. > -I../libio -I. -nostdinc -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed -isystem /usr/include > -D_LIBC_REENTRANT -include /sources/glibc-2.30/build/libc-modules.h > -DMODULE_NAME=libc -include ../include/libc-symbols.h > -DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS \ > -MD -MP -MF /sources/glibc-2.30/build/pthread-errnos.h.dT > \ > -MT '/sources/glibc-2.30/build/pthread-errnos.h.d > /sources/glibc-2.30/build/pthread-errnos.h'" \ > pthread-errnos.sym > /sources/glibc-2.30/build/pthread-errnos.hT > ########### > > After that, I carefully went over each step of making the Linux API headers > and compiling glibc. I discovered my error of using the old initrd file in > the boot manager configuration file. I fixed that and rebooted, then again > built the API headers for linux-5.5 and then tried glibc again. I got the > same endless loop. Then I tried the same thing with linux-5.4.13 and glibc, > which last week built with no issues. I got the same endless loop. > > Obviously something else has changed, but I have no clue what. Any ideas? > > Alan > Alan, If I've parsed your mail correctly, you are updating glibc on a completed system. If I've misparsed that, I'm sure I'll find out when I start my next test build. Very few people here update glibc in a running LFS system. Unlike binary distros, we don't ship a new build of glibc when the kernel headers change (or, indeed, at all - we don't ship any binaries). I myself have rebuilt glibc a couple of times in running systems: once was for an awkard issue related to sound, many years ago, and the more recent set of builds were when a vulnerability in glibc became known - again, several years ago. For the plain rebuild there was a very small change so I rebuilt the exact same version of glibc agaisnt the existing headers. For the more involved vulnerability fixes I _think_ I backported the fix to the versions I cared about, and rebuilt them in a similar way. What I had to do in each case was force a reboot immediately after installing the revised glibc (and I think I needed to use the power button). For the wider set of vulnerability fixes to past versions my memory says that one or more of the older versions I was still trying to keep usable failed (although with compilation errors, not a loop), and at that point I stopped trying to keep them usable - I think they were already several verisons behind current LFS at that time. TLDR; Don't update glibc on a running LFS system, or if you have to (vulnerability fixes) keep the same verison, same headers, and reboot as soon as it is installed - even then, no guarantees that it will be usable. Addendum: You are probably the only person rebuilding *everything* in the "Rolling Release" model - I think most of us take the view that while we will rebuild to fix vulnerabilities, or to fix bugs which affect our own use of the system, rebuilding everything is not for us. I know some people never rebuild anything on a completed system, I cannot recommend that but rebuilding everything is a waste of your time and electricity. OTOH I try to build new systems when we are coming up to releasing the next version of the books, and in between times for testing, so my systems only have a few months of being in currnet use, and then the versions that match book releases will typically get semi-maintained for a year or so (used to be longer, but too many problems in updating e.g. firefox on older toolchains). ĸen -- The politics of wizardry were either very simple, and resolved by someone ceasing to breathe, or as complex as one ball of yarn in a room with three bright-eyed little kittens. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
