This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Moritz Klammler <moritz at klammler dot eu>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Martin Sebor <msebor at gmail dot com>, Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Date: Thu, 22 Sep 2016 18:20:43 +0000
- Subject: Re: [RFC] Update gmp/mpfr/mpc minimum versions
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=softfail (sender IP is 10.152.10.59) smtp.mailfrom=hotmail.de; klammler.eu; dkim=none (message not signed) header.d=none;klammler.eu; dmarc=none action=none header.from=hotmail.de;
- References: <87ponvajvr.fsf@klammler.eu>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 09/22/16 20:07, Moritz Klammler wrote:
> Martin Sebor <msebor@gmail.com> writes:
>
>> [...]
>>
>>> In-tree only the versions that download_prerequisite picks are
>>> tested and guaranteed to work.
>>
>> I was made aware today that my recent patch for pr49905 broke
>> bootstrap with MPFR 2.4:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html
>>
>> In light of this risk and given that the recommended MPFR version
>> is still 2.4 I wonder if the download_prerequisites script shouldn't
>> instead download the minimum supported version. That way those of
>> us working with MPFR but not intimately familiar with its version
>> specific details would have an easier way of avoiding such breakage.
>>
>> Alternatively, perhaps the script could be extended to make it
>> possible to choose between the most recent and the recommended
>> versions of the prerequisites that GCC is intended to work with,
>> and people who make use of either in their code encouraged to
>> test with both.
>
> As some of you might already be aware of, I'm currently trying to get a
> new version of the `contrib/download_prerequisites` script approved that
> will verify the checksums of the tarballs it downloads and also provides
> additional options. If it is considered useful, I could add an option
> to it that would do what you suggest. Am I understanding correctly that
> we have a "minimum", "recommended" and "most recent" version for each
> dependency and that the script currently uses the "most recent" one? If
> the feature is wanted, all I'd need is somebody to tell me the version
> numbers.
>
No, the problem is, that these packages are not designed for in-tree
builds but for stand-alone. Likewise they are not designed for
cross-target builds. So for each version there are different
work-arounds necessary from the toplevel configure scripts.
And until I updated that top-level script, only the very old versions
did *actually* work on all targets.
Bernd.