ports/143529: [PATCH] math/py-numpy: does not build

[b. f.]

The following reply was made to PR ports/143529; it has been noted by GNATS.

From: "b. f." <bf1783 at googlemail.com>
To: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>
Cc: bug-followup at freebsd.org, amdmi3 at amdmi3.ru
Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
Date: Mon, 8 Feb 2010 04:19:59 -0500

 On 2/7/10, Li-Lun Wang (Leland Wang) <llwang at infor.org> wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 >
 > Hello,
 >
 > Unfortunately I couldn't reproduce the error in my 8.0 amd64 box or in
 > my 8.0 i386 tinderbox.
 >
 > b.f., I don't quite understand your comment.  The error message
 > apparently was about the system /usr/include/fenv.h rather than a
 > bundled fenv.h.  If you know what the issue is, could you please
 > provide me some more details?  Thanks.
 
 I have only seen this problem on my own 9-CURRENT amd64, when using
 lang/gcc45 and devel/binutilis, although I have had partial reports
 from two other users using gcc44 on FreeBSD 7.2 and 8.  The problem is
 summarized in:
 
 http://bugs.gentoo.org/279487
 
 where their "solution" is to switch FreeBSD to the fenv.h and fenv.c
 that were bundled with py-numpy:
 
 
 --- numpy/core/include/numpy/ufuncobject.h.orig 2009-07-28 15:04:42 -0400
 +++ numpy/core/include/numpy/ufuncobject.h      2009-07-28 15:05:58 -0400
 @@ -318,8 +318,10 @@
 
  #elif defined(__GLIBC__) || defined(__APPLE__) || defined(__CYGWIN__)
 || defined(__MINGW32__) || (defined(__FreeBSD__) && (__FreeBSD_version
 >= 502114))
 
 -#if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__)
 || defined(__FreeBSD__)
 +#if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__)
  #include <fenv.h>
 +#elif defined(__FreeBSD__)
 +#include "fenv/fenv.h"
  #elif defined(__CYGWIN__)
  #include "fenv/fenv.c"
  #endif
 --- numpy/numarray/_capi.c.orig 2009-07-28 15:18:13 -0400
 +++ numpy/numarray/_capi.c      2009-07-28 15:19:04 -0400
 @@ -8,8 +8,10 @@
  #include <sys/param.h>
  #endif
 
 -#if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__)
 || (defined(__FreeBSD__) && (__FreeBSD_version >= 502114))
 +#if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__)
  #include <fenv.h>
 +#elif (defined(__FreeBSD__) && (__FreeBSD_version >= 502114))
 +#include "numpy/fenv/fenv.h"
  #elif defined(__CYGWIN__)
  #include "numpy/fenv/fenv.h"
  #include "numpy/fenv/fenv.c"
 
 This fixes the build error because the numpy developers had made some
 earlier changes:
 
 ------------------------------------------------------------------------
 r5809 | cdavid | 2008-09-13 02:03:30 -0400 (Sat, 13 Sep 2008) | 6 lines
 
 Fix cygwin compilation
 
 Recent version of binutils (2.18.50) do not accept 4 bytes operand for some
 opcodes like fnstsw (which always expected a 2 bytes operand). Replace the type
 of the argument from unsigned 2 bytes to unsigned 4 bytes unsigned integer.
 
 Index: fenv.h
 ===================================================================
 --- fenv.h      (revision 5808)
 +++ fenv.h      (revision 5809)
 @@ -91,7 +91,7 @@
  static __inline int
  fegetexceptflag(fexcept_t *__flagp, int __excepts)
  {
 -       int __status;
 +       __uint16_t __status;
 
         __fnstsw(&__status);
         *__flagp = __status & __excepts;
 @@ -123,7 +123,7 @@
  static __inline int
  fetestexcept(int __excepts)
  {
 -       int __status;
 +       __uint16_t __status;
 
         __fnstsw(&__status);
         return (__status & __excepts);
 @@ -187,7 +187,7 @@
  static __inline int
  feupdateenv(const fenv_t *__envp)
  {
 -       int __status;
 +       __uint16_t __status;
 
         __fnstsw(&__status);
         __fldenv(*__envp);
 
 
 However, I think the gentoo solution is the wrong thing to do, for a
 number of reasons.  The bundled fenv.h is based on a very old,
 i386-specific version of our own system fenv.h, and was only intended
 by the numpy developers to be used on cygwin (i.e., Windows).  It does
 not include important changes that das@ and others have made in the
 past several years (protecting the i387 registers from being
 clobbered, handling SSE, changing the fe* function API, etc. -- See,
 for example:
 
 http://svn.freebsd.org/viewvc/base/head/lib/msun/i387/fenv.h?view=log&pathrev=203441
 
 ), and it may not handle other architectures properly (this code is
 machine-dependent).  numpy and python are linked to our system math
 libraries, which expect a certain default floating point behavior, so
 we don't want numpy to behave differently.  The right thing to do
 would probably be to use our system headers, but with the changes that
 were just made in:
 
 http://svn.freebsd.org/viewvc/base?view=revision&revision=203441
 
 You could bundle the latest versions of the headers with the port and
 include them instead of numpy's headers or the pre-r203441 system
 headers.  It wouldn't be the best fix -- that would be to get all
 users to use a version of FreeBSD with the post-r203441 headers -- but
 it would be the next best thing.
 
 
 b.