On Mon, Jan 29, 2018 at 11:42:31PM +0100, Edgar Alwers wrote:
>
>
> Am 29.01.2018 um 23:21 schrieb Paul Rogers:
> > I suggest you do as Bruce wrote.
> Accepted, Paul. The problem is, that I can only perform "lscpu" on the
> desktop in March, as I am not at home.
>
Your original post implied you would be at home until February,
which is why you got advice you could not implement.
> > And so it's *not* "working perfectly".
>
> I do not want to become philosophical. But for me, a system is working, well,
> perfectly, if it is doing all the jobs it was designed for. Compiling new
> programs do not belong to the normal tasks of a user, ok ?
But it does belong to the normal tasks of a sysadmin if he (in this
case) has chosen to compile from scratch. And the other
responsibilities of a sysadmin include looking out for
vulnerabilities, most of which are fixed by a patch or a new
version of a package (think ALL the graphical browsers, as well as
openssl, curl, ...) - in BLFS we only put those in the -dev book
(and the same for LFS, if something there gets a known
vulnerability).
I agree that many of the vulnerabilities are 'not very likely' if you
are careful with what websites you visit, but others are more likely,
particularly on a machine which is being used at other people's or
organizations' places (or even on wifi at a cafe).
> > *in general* you can no longer just port a LFS build to some arbitrary
> > machine
>
> It seems to be so, if this is not a GMP-issue alone. The consequence would be
> a "LFS" advice, that you are supposed to build the same LFS/BLFS system on
> each machine you own. from the scratch.
> Is this what you mean ?
>
> Edgar
>
I'm not Paul, but my advice is that the books expect you to build on
each machine. And I must admit, I too thought you had had a similar
problem in the past - but I could be mistaken.
Building on one machine to bootstrap a build on another _is_
possible, but it means using the fsf config files for BLFS, not
optimizing for the build machine in CFLAGS, CXXFLAGS (LFS and BLFS
don't do that, but people - even me, now - do that, and not building
very much of BLFS on the build machine. But I won't do that if I
intend to use the system to bootstrap a new machine.
More generally, a lot of audio/video packages will use whatever is
available on the build system, because they want to *run* as fast as
possible.
Alternatively, for packages which accept builder-specified CFLAGS,
CXXFLAGS, build for the lowest common denominator of your machines.
I think some of the audio/video packages NOT in BLFS have options
for this, but I would distrust many AV packages built on a newer
microarchitecture machine (or built on Intel and used on AMD, or vice
versa) - if they work, great, if not, no real surprise.
But the most important thing, once you decide you want to keep using
LFS, and therefore you know that from time to time you will need to
build a new one, is to have at least two LFS systems (current, and
space for next, becoming old and current after the next build). And
for that sort of setup, separate boot and home partitions are
useful. Then, if something goes wrong when updating the current
system you can go back to the previous system, chroot, and either
restore from a backup or fix the error.
Meanwhile, in this case Armin's advice looks like the easiest way
forward - until I read his post, I would have said that the approach
Pierre suggested (if you have a spare partition) was the only
plausible approach.
Final thought - when you build a new system which you expect to use
away from home, do *more* testing (not running test suites from
packages, I mean testing that it does what you need).
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
