Sent: Friday, January 31, 2020 at 5:19 AM From: "Alan Feuerbacher via blfs-support" <[email protected]> To: [email protected] Cc: "Alan Feuerbacher" <[email protected]> Subject: Re: [blfs-support] glibc-2.30 No Longer Builds, After Updating to Linux-5.5.0
On 1/29/2020 8:52 PM, Ken Moffat via blfs-support wrote: 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] Alan, If I've parsed your mail correctly, you are updating glibc on a completed system. Right. Completed, at least, to the point where KDE etc. can be installed. 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). That makes sense to me for the stable versions of LFS, but I thought the purpose of the development versions was for someone like me to install new packages as they come along. 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. I don't understand what that means. 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). So rebuilding glibc sort of clobbered your system? As I said, I rebuilt glibc-2.30 using headers from linux-5.4.8 and again with linux-5.4.13, and the system ran fine. At least, I *think* it did. Only when I tried with linux-5.5.0 did things go south. 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. I'll remember that. 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). And here I thought y'all kept up to date on all systems with your automatic build tools, kind of the way active distributions like Fedora do for you automatically. :-) The reasons I've wanted to install updated packages as they come along are partly my desire to keep *all* software up to date, and partly because doing so tends to teach me things that I would not learn otherwise. After all, on an introductory LFS page it's stated: << LFS teaches people how a Linux system works internally Building LFS teaches you about all that makes Linux tick, how things work together and depend on each other. And most importantly, how to customize it to your own tastes and needs. >> There's nothing like solving problems that teaches you so well about how systems tick. As for installing updated packages, the page "Read the Linux From Scratch Book Online" states: << Current Development This is the LFS systemd Book in its current development state. Whilst it may provide more features and updated upstream packages than the stable book, it is more prone to bugs and security vulnerabilities. >> The BLFS book says essentially the same thing: << Current Development This is the BLFS systemd Book in its current development state. Changes can happen that break the build of some packages temporarily. Since this version of the book is in constant change, there is no separate errata. >> To me these statements suggest that the purpose of making development versions available is to allow updating packages as they come along; otherwise one would want to stick with a Stable version. Am I misinterpreting that? What I vaguely have in mind, not knowing any better, is that by upgrading the current development version as changes come along, my system will gradually morph into what will become the Stable version for the next LFS go-around. In March, perhaps? I guess what I'm trying to do is a form of package management. Since I've barely gotten LFS installed as a working system and not yet sorted out many issues, I've not really considered package management in any detail. Anyway, here's what the LFS book says in section "6.3.1 Upgrade Issues": << If Glibc needs to be upgraded to a newer version, (e.g. from glibc-2.19 to glibc-2.20), it is safer to rebuild LFS. Though you may be able to rebuild all the packages in their dependency order, we do not recommend it. >> Clear enough, but that says nothing about my problem at hand: what should one do when the Linux kernel is updated but Glibc remains the same? As I understand the operation of Linux's dynamic libraries, one can change the underlying software without issues as long as the name of the dynamic library remains the same. Indeed, that's the purpose of dynamic libraries. If that's the case, why would updates to packages be a problem as long as the names of the dynamic libraries remained the same? Anyway, since beginning my LFS installation in late December I've successfully updated the kernel several times: 5.4.6 -> 5.4.8 -> 5.4.13 had no issues that I can see. But going to 5.5.0 seems to have broken something, but I don't know what. So for now, since the 5.4.13 installation seems mostly to work, I'll stop trying to update to 5.5.0. I still have the issue with Fluxbox, though: when I run configure, I get: << configure error: Your libstdc++ doesn't have the sstream or strstream classes >> To test things further, I've built several more packages successfully: openbox librep rep-gtk sawfish So I'll just move on for now, hoping I haven't broken something irreparably. Thanks for your help! Alan -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html[http://www.linuxfromscratch.org/blfs/faq.html] Unsubscribe: See the above information page Hello, I am going to say this because I am now PISSED OFF. Anyone who posts on multiple failures to install/upgrade software has no place using linux. If you are unable to comprehend the English language, and read what has been written and provided, do not expect people to hold your hand constantly. You are a waste of space on this list. No one is here to teach you. Learn for yourself by using google and actually getting a firm grip on the basics of linux. You do NOT have such knowledge. Format your computer and go back to WINDOWS. Christopher. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
