[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64



On 3 May 2018, at 09:21, Svante Signell <svante.signell@gmail.com> wrote:
> On Wed, 2018-05-02 at 12:51 +0100, James Clarke wrote:
>> Control: reassign -1 gcc-7
>> Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-
>> amd64
>> 
>> On 2 May 2018, at 10:38, Svante Signell <svante.signell@gmail.com> wrote:
>>> 
>>> Source: mpfr4
>>> Version: 4.0.1-1
>>> Severity: important
>>> Tags: patch
>>> User: debian-bsd@lists.debian.org
>>> Usertags: kfreebsd
>>> 
>>> Hi,
>>> 
>>> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the
>>> debian/libmpfr6.symbols
>>> file. Attached is a file with the symbols generated from the build:
>>> libmpfr6.symbols.kfreebsd-amd64.
>>> 
>>> Thanks!
>> 
>> You're right that the symbols file is currently wrong, but IMO gcc should have
>> decimal float support enabled for kfreebsd-amd64. It's enabled for
>> kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
>> kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a
>> future
>> 64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].
>> 
>> James
>> 
>> [0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26
> 
> Hi James,
> 
> I think it is unfortunate that you reassigned this bug to gcc-7. That will not
> solve the mpfr4 build on the buildds.
> 
> There are two ways to solve this problem:
> 1)
> - reassign this bug back to mpfr4, adding the libfr6.symbols.kfreebsd-amd64 in
> next version 4.0.1-2.

Well, if you wanted to do that, it should be by changing the (arch=...)
restriction lists in the main libfr6.symbols rather than forking a copy for
kfreebsd-amd64.

> - clone this bug to gcc-7, adding a patch to dfp.m4 so it can be integrated in
> next release of gcc-7: 7.3.0-18?

Personally I'd just get gcc patched and give back mpfr4.

> 2) (not preferred)
> - Build an NMUed version of mpfr4, 4.0.1-1.1, and install it at debian-ports. 

Indeed, unreleased uploads are best avoided when possible.

> For GNU/Hurd the entry in sources.list is
> deb http://ftp.ports.debian.org/debian-ports unreleased main
> 
> What about creating
> http://ftp.ports.debian.org/debian-ports/pool-kfreebsd-{amd64,i386} and populate
> the mpfr4 packages there at pool-kfreebsd-amd64/m/. Additionally the buildds
> need to use these packages. Unfortunately I don't know how to do that.

We could, and may well eventually need an unreleased suite, but not now.
Getting the buildds to see the suite would be simple; wanna-build would need a
copy of the hurd code to tell it that unreleased exists, and our buildd setup
scripts would need tweaking to add it to apt's sources in the chroots.

> Then when gcc-7-7.3.0-18 is released, an updated version of mpfr4 is hopefully
> available (if not, what to do, how to get back to using the old version?)

In such a situation, the updated version of mpfr4 in unstable would be picked
by `apt upgrade` as unstable and unreleased get the same priority by default,
just like how you automatically get security updates from stretch/updates for
packages installed from the stretch archive on ftp-master.

James


Reply to: