[lfs-dev] Are we ready for LFS-7.5?
lfs65 at cruziero.com
Sun Mar 2 04:38:42 PST 2014
> Date: Sun, 02 Mar 2014 03:06:12 +0100
> From: "Armin K." <krejzi at email.com>
> To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
> Subject: Re: [lfs-dev] Are we ready for LFS-7.5?
> >>>> I've just started sendmail. Actually I'm most interested in getting the
> >>>> slackware issue settled for LFS. That's our only holdup for release.
> >>>> -- Bruce
> >>> Why should we care when it's a distribution issue? Every "sane" distro
> > It's not a 'distribution issue': you're wrong.
> It is. Package ships *.la file that depends on another *.la file which
> no package ships that the former one depends on. Packaging error.
Nope, you're still misapprehending, to say the least, the picture here:
and perhaps being misled by a 'quick to condemn & cast out' approach rather
than a 'learn and understand' attitude; the world - and as we all know,
certain regions even more than others - doesn't need yet more of the former,
and could do with much more of the latter.
The 'a/aaa_elflibs...' package, like the 'a/aaa_base...' and
'a/aaa_terminfo...' packages are there to, inter alia, provide foundation to
the subsequent parts of the install: it's not intended - and the docs make
that quite clear - that you stop there and have an even minimal consistent
functioning system. The 'l/...' series &c fill in the rest of the install,
even for a minimal install.
Any distro has a sequence of steps that must be completed before they
are at the stage of a minimum, or full, &c, install. You don't just stop
partway through the LFS sequence, end up with a system that has 'gaps'
(e.g not booting), and yell that it's not a 'sane' distro, and why should
anyone care about it, and the 'packaging' (1 page ~= 1 pkg) is garbage
cos it didn't auto-prevent that issue, and so on.
That 'a/aaa_elflibs...' package that you're "going on" about, is
installed at approx the same stage as the 'a/aaa_base...' package: that
'a/aaa_base...' package is equivalent to __section **2.1**__ of the lfs book
('chapter02/creatingpartition.html'). You try stopping an lfs build that
early, and immediately label lfs as not 'sane', and not worth 'caring'
about, and its packaging system borken, and you just make yourself look
> >>> works just fine except slackware.
> > Slackware non-'pathological'-install works fine in this respect: you're
> > wrong.
> >>> So let them fix it instead of us.
> > What needs fixing is your rant borne from lack of understanding and goodness
> > knows what else ... .
> > Just to be perhaps even clearer:
> > --
> > * even a modicum of understanding of the thread - as opposed to some of
> > the recent off-the-cuff postings from the side - would let you realise
> > that a normal slackware installation is just fine for building gcc per
> > lfs instructions.
> > * it's not a distro issue per se: it's, roughly speaking, how gcc looks
> > into host-os and makes a slightly-less-than-rigourous assumption or two.
> > --
> >> The real core of the issue is how gcc is looking for mpfr/mpc/gmp .
> According to Pierre's test, it's mpc issue, not gcc. mpc tries to use
> host's libmpfr.la (for a static library it shouldn't matter if it uses
> host or bundled one imho), but it fails to do so because host's
> libmpfr.la tries to use host's libgmp.la which is not installed by any
> package that mpfr (should) depend(s) on.
Yes, that's taken as read, in both the new (2014) thread, and in the
original (2013) thread once it was clearer what was going on. The term
'gcc' is used as a shorthand - e.g. for the gcc build seq (incl sub-seq)
in lfs book - in the threads, where the context is clear to at least those
that are following the thread in good faith.
More information about the lfs-dev