Date: Fri, 3 Jan 2014 20:23:06 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Dimitry Andric <dim@FreeBSD.org>, Torbjorn Granlund <tg@gmplib.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: Advice about /usr/ports/math/gmp Message-ID: <20140103202306.0fd26803@kalimero.tijl.coosemans.org> In-Reply-To: <20140103183748.GA19702@ithaqua.etoilebsd.net> References: <86d2k9uhw1.fsf@shell.gmplib.org> <9D1C0F6F-0683-430D-AB96-3E29693B3163@FreeBSD.org> <20140103183748.GA19702@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Jan 2014 19:37:48 +0100 Baptiste Daroussin wrote: > On Fri, Jan 03, 2014 at 07:27:29PM +0100, Dimitry Andric wrote: >> On 03 Jan 2014, at 17:53, Torbjorn Granlund <tg@gmplib.org> wrote: >>> We are about to release GMP 5.2. >>> >>> We have been forced to add three FreeBSD-related items to the releases >>> notes: >>> >>> * This release will not work on FreeBSD/amd64 7.x, 8.x or 9 series >>> before 9.3 with a Haswell CPU or any other CPU which supports the >>> BMI2 instructions. The reason is that the FreeBSD m4 command is not >>> correctly implemented. (Workaround: Use an older GMP release, or >>> install GNU m4 from /usr/ports and tell GMP to use it.) >>> >>> * This release will not work on FreeBSD/amd64 before version 10 using >>> the 32-bit ABI. The reason is broken limits.h and broken dynamic >>> linking. (Workaround: Use an older GMP release if using the 32-bit >>> ABI on these FreeBSD releases is important.) >>> >>> * This release will not work on FreeBSD/amd64 10.0 using the 32-bit >>> ABI. The reason is bugs in the compiler 'clang'. (Workaround: >>> Compiling gcc from /usr/ports might work, except that gcc depends on >>> GMP; we have not been able to test that workaround since >>> FreeBSD/i386 10.0 does not work for us under KVM or Xen.) >>> >>> The first item is a show-stopper. It would be possible to implement a >>> workaround in GMP. We choose not to do that since (1) we adviced the >>> FreeBSD project two years ago the m4 bug, and FreeBSD chose to make 4 >>> releases without fixing m4, and (2) the fix is ugly, and (3) our use of >>> m4 which triggers the bug is actually part of a workaround for a broken >>> assembler (to much complexity to maintain workarounds for workarounds). >>> >>> The second item should not affect /usr/ports builds since they would use >>> the default 64-bit ABI on amd64 machines. >>> >>> The third item is a show-stopper until clang is fixed. We have not been >>> able to isolate this problem due to lack of time and due to a deeply >>> malfunctioning filesystem of FreeBSD/i386 under KVM and Xen+NetBSD. We >>> don't have any more information about these bugs. >>> >>> >>> We do not plan to implement workarounds for the above bugs for GMP 5.2.x >>> for any x. I would advice that you stick with GMP 5.1.3. >> >> Uhm, if you provide approximately zero information about these supposed >> "bugs", how do you expect anyone to help fixing them? > > In particular concerning m4, I'd like to hear what is buggy and how, our m4 do > respect the m4 specs: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html plus it has > support for some (all?) of the gnu extension via the -g option. > > If anything is buggy I would like to hear about it and fix. The first item is http://www.freebsd.org/cgi/query-pr.cgi?pr=166994 The second item is about compiling with -m32. We only fully implemented that in FreeBSD 10. The third item I don't know anything about.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140103202306.0fd26803>