On 12/01/2018 08:35 PM, Ken Moffat via blfs-support wrote:
Can you post your script?
I've updated glibc in the past, but usually to the same version with
one or more patches.
My scripts are specific to how I do things, but I think it should be
reasonable comprehensible. Five notes:
0. My scripts may differ from the book about the minimum kernel
version. I also like them to tell me what is going on, so I
separate the logging and let scripts write to the screen. Also, of
course, I mostly build as the big guy. And I have functions to do a
lot of things, albeit perhaps they are not ideal (e.g. logging what
got installed/updated is sloow on a fully-built system and uses a lot
of space while still needing manual review before saying "oh yes,
just delete all those files").
1. Fiddling about with GCCINCDIR or -isystem will cause configure to
fail. Adding a libv_cv value to get past that (what Matt
recommended to Andy in 2010) will start to build, but eventually ld
will fail because /usr/include is a directory. So just omit that
line.
2. The nscd and locale parts are not normally needed. I've kept the
comments because I once needed to reinstall locales. I suspect that
might have been when I tried to update glibc on some previous
LFS releases after the last big lot of vulnerabilities and had to
move to a newer version to get the fixes.
3. If I had put this in, I would have modified the explanation about
suppressing test-installation : on a *completed* LFS system it
failed after ld failed to load a couple of libnis* libraries.
4. After completing, Either fix it up (if unexpected test failures),
perhaps recover from a backup if tests failed (the script just runs
through after finding a build which ought to work, and allowing for
tests to fail), Or reboot ASAP. BUT when rebooting on sysv the LFS
umount script will fail, a message something like
umount: /: is busy.
That did give a clean filesystem after continuing, doing it on
systemd might be interesting (enabling MagicSysRQ on a machine is
always a good idea, unless untrusted people can access the
keyboard).
Thank you. It is helpful but it is also a bit hard to follow without
the /misc/packages and ${KM_SCRIPTS}/functions; but I see they are not
essential for understanding what you are doing.
What's happened to me in the past is when I do the 'make install' the
system no longer works. but I suppose if it is only a patch to the
current version then it would probably work.
I do not want to patch glibc in the lfs-dev book. It will automatically be
incorporated in the next glibc release which is scheduled before we release
the next version of LFS.
I have noted that you appear not to care greatly about
vulnerabilities unless they are accompanied by a new release. But
in BLFS we can often find a patch to solve the problem.
That's true on both counts. My general position is that if upstream
does not think it is important enough to do a release, why should we?
Not all bugs, even CVEs, are equal.
What I really don't want to do is the extra work of creating a patch and
updating the book when a new release then creates more work to remove
that patch from the book.
If anyone is running a production system based on our -dev books, then I
question that decision.
This also applies to our 8.3 *release*. And if anybody is running a
production system based on LFS/BLFS (and I have heard of people
doing that) they need to make their own decisions about
vulnerabilities - for many packages, running with what was in our
last release will expose you to known problems. Mostly, a single
problem on its own will not pwn you - but as in this case a DOS is
possible. For a home user just amusing themself on their own LFS
system, a DOS is not usually a big problem.
For our 8,3 release, then the comments should go in the errata. It's
not very likely that a user of a 8.3 release will look in the -dev book.
I do note that the patch you included only really changes 3 significant
lines:
+ }
...
+ switch (model)
+ {
Comments, NEWS, and ChangeLog don't affect the build,
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
