Date: Mon, 8 Feb 2010 09:30:03 GMT From: "b. f." <bf1783@googlemail.com> To: freebsd-python@FreeBSD.org Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build Message-ID: <201002080930.o189U3fP098171@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/143529; it has been noted by GNATS. From: "b. f." <bf1783@googlemail.com> To: "Li-Lun Wang (Leland Wang)" <llwang@infor.org> Cc: bug-followup@freebsd.org, amdmi3@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201002080930.o189U3fP098171>