On Thu, Jan 30, 2020 at 09:19:41AM -0700, Alan Feuerbacher via blfs-support
wrote:
> 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:
> > > 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.
Yes, I suppose that strictly I meant that LFS was completed.
> > >
> > > 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.
Backport: The change was probably only a few lines in a couple of
files, so I manually made the changes (different line numbers or
changed context, so the patch from a newer version did not apply)
and rediffed. Then I did the scripted update of glibc.
> > > 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?
Yes, as expected. But after managing to reboot (possibly Alt-SysRQ,
possibly it really was a hard poweroff - I forget) and running the
automatic fsck on the next boot it was all fine.
> 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.
>
The problem with kernel headers is that things change, and in some
cases that can cause glibc to use different code.
> There's nothing like solving problems that teaches you so well
> about how systems tick.
>
Indeed.
>
> 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?
>
A stable version was a snapshot which received more testing and
appeared to be ok at the time. That doesn't mean that every
possible combination of dependencies, or every possible usage of
complex applications, has been tested.
In any case, you still need to update for vulnerabilities, e.g. I
use falkon as my second desktop browser (apart from that I avoid
kde). I had been using "stable" qt-5.12 (for the way we build
qtwebengine, only updating webengine without the rest of kde used to
save an hour or three per system). But 5.12.late gave problems on
recent systems and in any case current fixes seem to appear in the
latest series first, so although I had some systems using 5.13 I
moved everything to 5.14.1 this week (and that would anyway require
qt-5.14.1 because of CVE fixes in the non-webengine part).
A most unpleasant process that was - random ftbfs from webengine
without any obvious error messages (thousands of files with error in
the name, functions with error in the name which reported warnings,
final message sometihng like 'subproject failed'. Worked on second
attempts. And then I had to update all three of the packages I have
which use qt (falkon, g'mic, vlc). Fun is not an adequate
description.
> 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 suspect we will start testing in early February, at which point
versions will start to freeze.
> 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.
Package Management is a fun area. People who use jhalfs pick up
recommended deps but tend not to benefit from any optional deps
which happen to need additional options in configure/cmake/meson.
People who use a Makefile to list the deps, in the way Ag mentioned,
need to be aware of changed dependencies and also might have
problems if make decides several packages can be built in parallel
but one of those is big AND uses ninja or rust (which think they own
the machine).
My approach is to try to thoroughly list the files before and after
an install (although that tends to break if the install fails), and
getting to a situation that mostly works took a long while (things
like headers and docs dated before the package was untarred, and
then files which got _changed_ durign the install). More generally,
doing a DESTDIR (INSTALL_ROOT for qt and something like that for
glibc!) usually shows which files will be installed or updated.
Anyway, people who stick with LFS/BLFS tend to be "the awkward
squad" and we all have different requirements for package
management.
> 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?
>
Easy: Update the kernel. If you use an initrd also update that.
Manually edit grub.cfg so that the old kernel is still available for
those occasions where the new version has some other problem (I'm
not sure what the equivalent is for refind (?) that you said you
were using).
But you need to know _why_ you are updating the kernel. LFS usually
uses the current "leading edge" kernel. For released kernels which
are still supported at kernel.org ('stable') there may be two point
updates in a week - generally it isn't worth rebuilding for each
point release, but you need to keep an eye open for new
vulnerability fixes. e.g. I think the latest (intel) vulnerabiity
was worked around this week in 5.4.15 and is fixed in 5.5.0.
My oldest maintained systems are now 8.3. I try to build lateish
rc kernels to look out for problems in my usage, then update to the
next version. When my systems for a release become non-current I
still try to fix the main vulnerabilities and I tend to move to the
current long-term upstream stable kernel at that point (now 5.4).
OTOH, for newer hardware I might need to keep using newer kernels -
when I first got my Zen APUs 4.19 was the current LTS but that is
too old for those machines (it tries to load radeon instead of
amdgpu, but fails because the required firmware is only for amdgpu:
fortunately 5.4 is now LTS so that problem for me is gone).
> 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.
>
Yes, but glibc is special. When updating a 'normal' dynamic lib the
processes already running continue to use the old version. So for
libraries used by X you need to stop X. For glibc, everything uses
it.
Also, a number of libraries do not keep the soname across versions,
so always look if anything is using a lib before thinking "I updated
that, I can delete the old lib".
> 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 >>
>
Google finds some results for that, but from 2004 to 2007 and fixed
by moving to a newer g++ (e.g. moving to 3.3!). Looks like you
might have problems with anything which uses those classes.
If you updated the headers for 5.4.13 I guess that could have a
similar change to 5.5.0 (Greg KH tries to be bug-compatible with Linus).
> 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
> //
>
--
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
