> Date: Sun, 02 Mar 2014 11:11:50 +0100
> From: Pierre Labastie <pierre.labas...@neuf.fr>
> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org>
> Subject: Re: [lfs-dev] gcc pass 1/2 instructions re mpfr/gmp/mpc.
>
.
<snipped, as seems to maybe be snagging on some filter.>
.
>
> But useless!!!
>
Thanks for the reminder and re-pointing to .la ;] .
> lib{gmp,mpfr,mpc}.so _are_ there on all recent enough (less than 3 years or
> so) distro, since they are needed by gcc. And we do not want to use them in
> the build (that's the primary reason for unpacking the gmp, mpfr, mpc tarballs
> into the gcc-pass1 tree). The issue comes from the .la files, because there is
> no way to prevent libtool to use those from the host.
>
> Of course, usually, .la files do not exist (neither Debian, Fedora nor Arch
> provide asingle package with one of them). But they do exist on LFS and
> Slackware at least (if user does not delete them of course).
>
> What I would do is not putting any test for now, and when a similar issue pops
> out on -support, ask users to delete .la files. Or advise in the errata that
> .la files should be removed.
>
Yes, that's still of course an option, per the 'if wide-enough problem'
note in orig/early msg in present thread.
But what instructions would you put in the errata re removal? Would it
entail a find() &c: if so, then why not incorp that search into host-sys-reqs
and give a warning if the relevant .la items exist ?
> Coming to whether Slackware is botched or not, as a newbie to this distro, I
> would say that, since the packaging system allows to install packages without
> their deps, and that is advertised in the docs, it is not Slackware fault if
> the users (at least Hazel and me) want to do something else.
Yes, exactly. Yet we see much-less-informed 'decisions' that it's distro
x's fault and distro x is beyond stupid, etc ... ; in any event, the
idea that the likes of Slackware's level of technical ability would be
decided upon in such an environment as in parts of this thread (and in
the original 2013 thread), is risible - talk about adding negatively to
the sum of knowledge ... .
((As for slackware's package system: yes, there's pros'n'cons of its
loose coupling of deps. E.g. right now it's being availed of to flip
a couple of 32-bit servers over to 64-bit largely in-situ (for various
reasons), and relatively straightforwardly; it's not a 'supported' use of
the system/facilities; and if it should break (yes there's been plenty of
pre-testing) then we don't yell that it's a not "sane" distro, or broken,
or other such nonsense.
))
Kudos again to Hazel and you for examining the issue objectively and as-is,
and going by the 'experimental' evidence. It's good that the scientific
method still prevails.
rgds,
akh
>
> Regards
> Pierre
> --
>
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
