Le 02/03/2014 02:35, akhiezer a écrit :
>> Date: Sat, 01 Mar 2014 18:17:42 -0600
>> From: Bruce Dubbs <bruce.du...@gmail.com>
>> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org>
>> Subject: Re: [lfs-dev] gcc pass 1/2 instructions re mpfr/gmp/mpc.
>>
>> akhiezer wrote:
>>>> Date: Sat, 01 Mar 2014 17:04:38 -0600
>>>> From: Bruce Dubbs <bruce.du...@gmail.com>
>>>> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org>
>>>> Subject: Re: [lfs-dev] gcc pass 1/2 instructions re mpfr/gmp/mpc.
>>>>
>>>> Pierre Labastie wrote:
>>>>> Le 01/03/2014 23:31, Bruce Dubbs a écrit :
>>>>>> Pierre Labastie wrote:
>>>>>>> Le 01/03/2014 21:14, Bruce Dubbs a écrit :
>>>>>>>> Pierre Labastie wrote:
>>>>>>>>
>>>>>>>>>> It sounds like we need to add a check for libgmp on the host.
>>>>>>>>>> Perhaps
>>>>>>>>>> libmpfr and libmpc also.
>>>>>>>>
>>>>>>>>> It is the .la files, which fire the issue. I could reproduce the
>>>>>>>>> error with
>>>>>>>>> lfs-7.5-rc1 as the host, by removing libgmp.la.
>>>>>>>>>
>>>>>>>>> Actually, neither Debian nor Arch provide those .la files. I have not
>>>>>>>>> checked
>>>>>>>>> Fedora yet.
>>>>>>>>>
>>>>>>>>> I am not sure what should be done. If users accept to install
>>>>>>>>> libgmp-dev,
>>>>>>>>> libmpfr-dev, libmpc-dev on their host, the easiest would be to
>>>>>>>>> completely
>>>>>>>>> remove the build of those packages for gcc-pass1. I'll try that. This
>>>>>>>>> would
>>>>>>>>> imply that the host requirement be augmented with both libraries
>>>>>>>>> _and_ headers
>>>>>>>>> checks.
>>>>>>>>>
>>>>>>>>> Otherwise, maybe just a note telling to remove the .la files
>>>>>>>>> (completely
>>>>>>>>> removing them gives the cleanest build), at least for the course of
>>>>>>>>> the build?
>>>>>>>>
>>>>>>>> Yes, on my system I have /usr/lib/libmpfr.la which contains
>>>>>>>> dependency_libs=' /usr/lib/libgmp.la'.
>>>>>>>>
>>>>>>>> If we add the following to the host system requirements, would that be
>>>>>>>> enough?
>>>>>>>>
>>>>>>>> [ -e /usr/lib/libmpfr.la ] && [ ! -e /usr/lib/libgmp.la ] &&
>>>>>>>> echo "libgmp is missing"
>>>>>>>>
>>>>>>>> I'm going to hold off releasing 7.5 until we get this settled.
>>>>>>>>
>>>>>>>> -- Bruce
>>>>>>>>
>>>>>>> I think it is the idea of the fix, except that the libs may be in
>>>>>>> /usr/lib64
>>>>>>> (as in Slackware64). The message should be changed though, since
>>>>>>> libgmp.so
>>>>>>> might be installed without libgmp.la. Do not know exactly what to say:
>>>>>>> "please
>>>>>>> install a package with libgmp.la, or remove libmpfr.la" (too long...)
>>>>>>
>>>>>> Hmm. How about:
>>>>>>
>>>>>> if [ $(ls /usr/lib*/lib{mpfr,gmp,mpc}.so|wc -l) != 3 ]; then
>>>>>> echo one of lib{mpfr,gmp,mpc}.so is missing
>>>>>> fi
>>>>>>
>>>
>>>
>>> This would give a false-negatve on e.g. host-os multilib slackware - there's
>>> a '/usr/lib/libmpc.so' as well as the three 'usual suspects'
>>> (i.e. /usr/lib64/lib{mpfr,gmp,mpc}.so) in /usr/lib64 .
>>>
>>>
>>> The test - if using that approach - would really need to do (loop across)
>>> each of mpfr/mpc/gmp separately, and check that iindivid value is e.g. '>=1'
>>> && '<=2' .
>>
>>
>> Gawd.
>>
>> How about $(ls /usr/lib*/lib{mpfr,gmp,mpc}.so|sort|uniq|wc -l) != 3
>>
>
>
> Had written (it seems to've not appeared on list):
> ====
> No; you'd need to strip out the paths - or sed out the '64' &c - to get
> uniqueness. Can see by inspection: and verified on nearby machine, that
> still get =4 .
>
>
> Could may be do:
>
> $(ls /usr/lib*/lib{mpfr,gmp,mpc}.so|rev|cut -d'/' -f1|rev|sort|uniq|wc -l) !=
> 3
>
> , if it's ok to assume 'rev' present on host-os; probly ok as is usually in
> util-linux.
>
> Or could use find().
> ====
>
>
> But, that'd still be not right: for, you could be inadvertently
> mixing'n'matching 32-bit & 64-bit: e.g. (just an example) 32-bit gmp under
> /usr/lib , and 64-bit mpfr & mpc under /usr/lib64 . You'd really want to
> keep them separate:
>
> $(\ls /usr/lib/lib{mpfr,gmp,mpc}.so|rev|cut -d'/' -f1|rev|sort|uniq|wc -l)
> != 3
>
> $(\ls /usr/lib64/lib{mpfr,gmp,mpc}.so|rev|cut -d'/' -f1|rev|sort|uniq|wc
> -l) != 3
>
> , with a conditional test beforehand to ensure the dir (/usr/lib ,
> /usr/lib64) exists.
>
>
>
> That'd still allow a reasonably concise and accurate test.
>
But useless!!!
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.
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.
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
