Bug 143529 - [PATCH] math/py-numpy: does not build
Summary: [PATCH] math/py-numpy: does not build
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-python (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-03 15:30 UTC by Dmitry Marakasov
Modified: 2010-09-12 13:30 UTC (History)
1 user (show)

See Also:


Attachments
gcc44_binutils_configure.diff (10.58 KB, patch)
2010-02-16 03:10 UTC, b. f.
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov 2010-02-03 15:30:01 UTC
---
gcc44: numpy/core/src/multiarray/multiarraymodule_onefile.c
cc -shared -pthread -O2 -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 -fno-strict-aliasing build/temp.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/multiarray/multiarraymodule_onefile.o -Lbuild/temp.freebsd-8.0-RELEASE-i386-2.6 -lnpymath -lm -o build/lib.freebsd-8.0-RELEASE-i386-2.6/numpy/core/multiarray.so
building 'numpy.core.umath' extension
compiling C sources
C compiler: gcc44 -DNDEBUG -O2 -pipe -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -O2 -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 -fno-strict-aliasing -fPIC

creating build/temp.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath
compile options: '-Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/include/python2.6 -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/multiarray -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath -c'
gcc44: numpy/core/src/umath/umathmodule_onefile.c
/usr/include/fenv.h: Assembler messages:
/usr/include/fenv.h:156: Error: suffix or operands invalid for `fnstsw'
/usr/include/fenv.h: Assembler messages:
/usr/include/fenv.h:156: Error: suffix or operands invalid for `fnstsw'
error: Command "gcc44 -DNDEBUG -O2 -pipe -march=prescott -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -O2 -pipe -march=prescott -Wl,-rpath=/usr/local/lib/gcc44 -fno-strict-aliasing -fPIC -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/include/python2.6 -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/multiarray -Ibuild/src.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath -c numpy/core/src/umath/umathmodule_onefile.c -o build/temp.freebsd-8.0-RELEASE-i386-2.6/numpy/core/src/umath/umathmodule_onefile.o" failed with exit status 1
*** Error code 1

Stop in /pool/ports/math/py-numpy.
*** Error code 1

Stop in /pool/ports/math/py-numpy.
---

Port maintainer (llwang@infor.org) is cc'd.

Generated with FreeBSD Port Tools 0.99

How-To-Repeat: make
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2010-02-03 15:30:15 UTC
Responsible Changed
From-To: freebsd-ports-bugs->freebsd-python

freebsd-python@ wants this port PRs (via the GNATS Auto Assign Tool)
Comment 2 Edwin Groothuis freebsd_committer freebsd_triage 2010-02-03 15:30:18 UTC
Maintainer of math/py-numpy,

Please note that PR ports/143529 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143529

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 3 Edwin Groothuis freebsd_committer freebsd_triage 2010-02-03 15:30:20 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 4 b. f. 2010-02-03 16:03:56 UTC
This is a known issue.  The port needs to be patched to use the system
fenv.h, rather than the bundled fenv.h, which is an outdated version
that does not include some important changes made to the system
headers and libraries made by das@ since 2004.  I'm a bit surprised
that this port has received so little attention of late, considering
the number of people that want to use it.

b.
Comment 5 Li-Lun Wang 2010-02-08 04:17:56 UTC
-----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.

- -- llwang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iD8DBQFLb5BzCQM7t5B2mhARAtjwAJ4vfZpn77nDWXkwDUI05KS1NV2vGgCfWW4I
RXdHB7Yp9C/r88BE0gEELgk=
=6sMj
-----END PGP SIGNATURE-----
Comment 6 b. f. 2010-02-08 09:19:59 UTC
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.
Comment 7 Li-Lun Wang 2010-02-15 04:50:24 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following patch will fix the problem.  It first detects if
binutils>=2.18.50 is installed.  If it is, then it patches numpy so
that the new fenv.h will be used if __FreeBSD_version <= 900009.

- -- llwang

diff -urN py-numpy.orig/Makefile py-numpy/Makefile
- --- py-numpy.orig/Makefile	2010-02-07 12:08:47.306031963 -0600
+++ py-numpy/Makefile	2010-02-14 22:41:50.085214000 -0600
@@ -59,6 +59,10 @@
 
 GCCLIBDIR=	`${FC} -print-file-name=libgfortran.so|${SED} -e s/libgfortran.so//`
 pre-configure:
+	@if ${PKG_INFO} 'binutils>=2.18.50' > /dev/null 2>&1 ; then \
+	${CP} ${FILESDIR}/fenv.h ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
+	${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
+ 	fi
 .ifdef WITH_ATLAS
 	@${REINPLACE_CMD} -e "s+%%GCCLIBDIR%%+${GCCLIBDIR}+" \
 	    -e "s+%%LOCALBASE%%+${LOCALBASE}+g" \
diff -urN py-numpy.orig/files/fenv.h py-numpy/files/fenv.h
- --- py-numpy.orig/files/fenv.h	1969-12-31 18:00:00.000000000 -0600
+++ py-numpy/files/fenv.h	2010-02-14 22:15:04.765373000 -0600
@@ -0,0 +1,252 @@
+/*-
+ * Copyright (c) 2004-2005 David Schultz <das@FreeBSD.ORG>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef	_FENV_H_
+#define	_FENV_H_
+
+#include <sys/cdefs.h>
+#include <sys/_types.h>
+
+/*                   
+ * To preserve binary compatibility with FreeBSD 5.3, we pack the
+ * mxcsr into some reserved fields, rather than changing sizeof(fenv_t).
+ */
+typedef struct {
+	__uint16_t	__control;
+	__uint16_t      __mxcsr_hi;
+	__uint16_t	__status;
+	__uint16_t      __mxcsr_lo;
+	__uint32_t	__tag;
+	char		__other[16];
+} fenv_t;
+
+#define	__get_mxcsr(env)	(((env).__mxcsr_hi << 16) |	\
+				 ((env).__mxcsr_lo))
+#define	__set_mxcsr(env, x)	do {				\
+	(env).__mxcsr_hi = (__uint32_t)(x) >> 16;		\
+	(env).__mxcsr_lo = (__uint16_t)(x);			\
+} while (0)
+
+typedef	__uint16_t	fexcept_t;
+
+/* Exception flags */
+#define	FE_INVALID	0x01
+#define	FE_DENORMAL	0x02
+#define	FE_DIVBYZERO	0x04
+#define	FE_OVERFLOW	0x08
+#define	FE_UNDERFLOW	0x10
+#define	FE_INEXACT	0x20
+#define	FE_ALL_EXCEPT	(FE_DIVBYZERO | FE_DENORMAL | FE_INEXACT | \
+			 FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW)
+
+/* Rounding modes */
+#define	FE_TONEAREST	0x0000
+#define	FE_DOWNWARD	0x0400
+#define	FE_UPWARD	0x0800
+#define	FE_TOWARDZERO	0x0c00
+#define	_ROUND_MASK	(FE_TONEAREST | FE_DOWNWARD | \
+			 FE_UPWARD | FE_TOWARDZERO)
+
+/*
+ * As compared to the x87 control word, the SSE unit's control word
+ * has the rounding control bits offset by 3 and the exception mask
+ * bits offset by 7.
+ */
+#define	_SSE_ROUND_SHIFT	3
+#define	_SSE_EMASK_SHIFT	7
+
+__BEGIN_DECLS
+
+/* After testing for SSE support once, we cache the result in __has_sse. */
+enum __sse_support { __SSE_YES, __SSE_NO, __SSE_UNK };
+extern enum __sse_support __has_sse;
+int __test_sse(void);
+#ifdef __SSE__
+#define	__HAS_SSE()	1
+#else
+#define	__HAS_SSE()	(__has_sse == __SSE_YES ||			\
+			 (__has_sse == __SSE_UNK && __test_sse()))
+#endif
+
+/* Default floating-point environment */
+extern const fenv_t	__fe_dfl_env;
+#define	FE_DFL_ENV	(&__fe_dfl_env)
+
+#define	__fldcw(__cw)		__asm __volatile("fldcw %0" : : "m" (__cw))
+#define	__fldenv(__env)		__asm __volatile("fldenv %0" : : "m" (__env))
+#define	__fldenvx(__env)	__asm __volatile("fldenv %0" : : "m" (__env)  \
+				: "st", "st(1)", "st(2)", "st(3)", "st(4)",   \
+				"st(5)", "st(6)", "st(7)")
+#define	__fnclex()		__asm __volatile("fnclex")
+#define	__fnstenv(__env)	__asm __volatile("fnstenv %0" : "=m" (*(__env)))
+#define	__fnstcw(__cw)		__asm __volatile("fnstcw %0" : "=m" (*(__cw)))
+#define	__fnstsw(__sw)		__asm __volatile("fnstsw %0" : "=am" (*(__sw)))
+#define	__fwait()		__asm __volatile("fwait")
+#define	__ldmxcsr(__csr)	__asm __volatile("ldmxcsr %0" : : "m" (__csr))
+#define	__stmxcsr(__csr)	__asm __volatile("stmxcsr %0" : "=m" (*(__csr)))
+
+static __inline int
+feclearexcept(int __excepts)
+{
+	fenv_t __env;
+	__uint32_t __mxcsr;
+
+	if (__excepts == FE_ALL_EXCEPT) {
+		__fnclex();
+	} else {
+		__fnstenv(&__env);
+		__env.__status &= ~__excepts;
+		__fldenv(__env);
+	}
+	if (__HAS_SSE()) {
+		__stmxcsr(&__mxcsr);
+		__mxcsr &= ~__excepts;
+		__ldmxcsr(__mxcsr);
+	}
+	return (0);
+}
+
+static __inline int
+fegetexceptflag(fexcept_t *__flagp, int __excepts)
+{
+	__uint32_t __mxcsr;
+	__uint16_t __status;
+
+	__fnstsw(&__status);
+	if (__HAS_SSE())
+		__stmxcsr(&__mxcsr);
+	else
+		__mxcsr = 0;
+	*__flagp = (__mxcsr | __status) & __excepts;
+	return (0);
+}
+
+int fesetexceptflag(const fexcept_t *__flagp, int __excepts);
+int feraiseexcept(int __excepts);
+
+static __inline int
+fetestexcept(int __excepts)
+{
+	__uint32_t __mxcsr;
+	__uint16_t __status;
+
+	__fnstsw(&__status);
+	if (__HAS_SSE())
+		__stmxcsr(&__mxcsr);
+	else
+		__mxcsr = 0;
+	return ((__status | __mxcsr) & __excepts);
+}
+
+static __inline int
+fegetround(void)
+{
+	__uint16_t __control;
+
+	/*
+	 * We assume that the x87 and the SSE unit agree on the
+	 * rounding mode.  Reading the control word on the x87 turns
+	 * out to be about 5 times faster than reading it on the SSE
+	 * unit on an Opteron 244.
+	 */
+	__fnstcw(&__control);
+	return (__control & _ROUND_MASK);
+}
+
+static __inline int
+fesetround(int __round)
+{
+	__uint32_t __mxcsr;
+	__uint16_t __control;
+
+	if (__round & ~_ROUND_MASK)
+		return (-1);
+
+	__fnstcw(&__control);
+	__control &= ~_ROUND_MASK;
+	__control |= __round;
+	__fldcw(__control);
+
+	if (__HAS_SSE()) {
+		__stmxcsr(&__mxcsr);
+		__mxcsr &= ~(_ROUND_MASK << _SSE_ROUND_SHIFT);
+		__mxcsr |= __round << _SSE_ROUND_SHIFT;
+		__ldmxcsr(__mxcsr);
+	}
+
+	return (0);
+}
+
+int fegetenv(fenv_t *__envp);
+int feholdexcept(fenv_t *__envp);
+
+static __inline int
+fesetenv(const fenv_t *__envp)
+{
+	fenv_t __env = *__envp;
+	__uint32_t __mxcsr;
+
+	__mxcsr = __get_mxcsr(__env);
+	__set_mxcsr(__env, 0xffffffff);
+	/*
+	 * XXX Using fldenvx() instead of fldenv() tells the compiler that this
+	 * instruction clobbers the i387 register stack.  This happens because
+	 * we restore the tag word from the saved environment.  Normally, this
+	 * would happen anyway and we wouldn't care, because the ABI allows
+	 * function calls to clobber the i387 regs.  However, fesetenv() is
+	 * inlined, so we need to be more careful.
+	 */
+	__fldenvx(__env);
+	if (__HAS_SSE())
+		__ldmxcsr(__mxcsr);
+	return (0);
+}
+
+int feupdateenv(const fenv_t *__envp);
+
+#if __BSD_VISIBLE
+
+int feenableexcept(int __mask);
+int fedisableexcept(int __mask);
+
+static __inline int
+fegetexcept(void)
+{
+	__uint16_t __control;
+
+	/*
+	 * We assume that the masks for the x87 and the SSE unit are
+	 * the same.
+	 */
+	__fnstcw(&__control);
+	return (~__control & FE_ALL_EXCEPT);
+}
+
+#endif /* __BSD_VISIBLE */
+
+__END_DECLS
+
+#endif	/* !_FENV_H_ */
diff -urN py-numpy.orig/files/fenv.patch py-numpy/files/fenv.patch
- --- py-numpy.orig/files/fenv.patch	1969-12-31 18:00:00.000000000 -0600
+++ py-numpy/files/fenv.patch	2010-02-14 22:08:28.635395000 -0600
@@ -0,0 +1,28 @@
+--- numpy/numarray/_capi.c.orig	2009-12-28 08:00:09.000000000 -0600
++++ numpy/numarray/_capi.c	2010-02-14 22:04:48.315355420 -0600
+@@ -9,7 +9,11 @@
+ #endif
+ 
+ #if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__) || (defined(__FreeBSD__) && (__FreeBSD_version >= 502114))
++#if defined(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "numpy/fenv/fenv.h"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "numpy/fenv/fenv.h"
+ #include "numpy/fenv/fenv.c"
+--- numpy/core/include/numpy/ufuncobject.h.orig	2009-12-15 06:47:53.000000000 -0600
++++ numpy/core/include/numpy/ufuncobject.h	2010-02-14 22:07:51.055356085 -0600
+@@ -306,7 +306,11 @@
+ #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(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "numpy/fenv/fenv.h"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "fenv/fenv.c"
+ #endif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iD8DBQFLeNKOCQM7t5B2mhARAsT9AKCEL/5t3VTuNSA/vCljXo5gB1eHNQCfaSHs
+hY8PH6JtWZ+1/02OerSQaQ=
=jYmR
-----END PGP SIGNATURE-----
Comment 8 b. f. 2010-02-15 12:13:43 UTC
>From: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>
>To: bug-followup at FreeBSD.org
>Cc:
>Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
>Date: Mon, 15 Feb 2010 12:50:24 +0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

>The following patch will fix the problem.  It first detects if
> binutils>=2.18.50 is installed.  If it is, then it patches numpy so
> that the new fenv.h will be used if __FreeBSD_version <= 900009.

This fixes the build problem on i386 (although we're stuck with
possible run-time problems when numpy is built with the newer binutils
until the latest fenv.h changes are backported to all supported
versions of FreeBSD), but this code is machine-dependent, and fenv.h
needs to be selected based on ARCH.

You might do instead something like:

...
.if exists(${LOCALBASE}/bin/as)
.if ${ARCH} == "i386"
FP_ARCH= i387
.else
FP_ARCH= ${ARCH}
.endif
MASTER_SITES+= http://svn.freebsd.org/base/head/lib/msun/%SUBDIR%/:fp
MASTER_SITE_SUBDIR+= ${FP_ARCH}/:fp
DISTFILES+= fenv.h:fp
.endif
...
  pre-configure:
 .if exists(${LOCALBASE}/bin/as)
     ${CP} ${DISTDIR}/fenv.h ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
     ${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
.endif
...
Comment 9 b. f. 2010-02-15 12:58:47 UTC
On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
>>From: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>
>>To: bug-followup at FreeBSD.org
>>Cc:
>>Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
>>Date: Mon, 15 Feb 2010 12:50:24 +0800
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>>The following patch will fix the problem.  It first detects if
>> binutils>=2.18.50 is installed.  If it is, then it patches numpy so
>> that the new fenv.h will be used if __FreeBSD_version <= 900009.
>
> This fixes the build problem on i386 (although we're stuck with
> possible run-time problems when numpy is built with the newer binutils
> until the latest fenv.h changes are backported to all supported
> versions of FreeBSD), but this code is machine-dependent, and fenv.h
> needs to be selected based on ARCH.
>
> You might do instead something like:
>
> ...
> .if exists(${LOCALBASE}/bin/as)
> .if ${ARCH} == "i386"
> FP_ARCH= i387
> .else
> FP_ARCH= ${ARCH}
> .endif
> MASTER_SITES+= http://svn.freebsd.org/base/head/lib/msun/%SUBDIR%/:fp
> MASTER_SITE_SUBDIR+= ${FP_ARCH}/:fp
> DISTFILES+= fenv.h:fp
> .endif
> ...
>   pre-configure:
>  .if exists(${LOCALBASE}/bin/as)
>      ${CP} ${DISTDIR}/fenv.h ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h;
> \
>      ${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
> .endif
> ...
>

I should note that a specific snapshot of the headers may be preferred
to head, to ease maintenance.  You may also wish to add some specific
provisions for the "makesum" target.

This problem is occurring with lang/gcc44 from Ports, when
devel/binutils is installed, because then the latest gcc44 snapshots
are automatically preferring devel/binutils to the base system
binutils.  This is a bug in the lang/gcc44 port, and it should be
explicitly instructed to use one or the other (either hardcoded, or
based upon an OPTION), as lang/gcc45 is now wired to devel/binutils.
I have cc'ed the gcc maintainer.

b.
Comment 10 b. f. 2010-02-15 15:11:12 UTC
On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
> On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
>>>From: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>
>>>To: bug-followup at FreeBSD.org
>>>Cc:
>>>Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
>>>Date: Mon, 15 Feb 2010 12:50:24 +0800
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>
>>>The following patch will fix the problem.  It first detects if
>>> binutils>=2.18.50 is installed.  If it is, then it patches numpy so
>>> that the new fenv.h will be used if __FreeBSD_version <= 900009.
>>
>> This fixes the build problem on i386 (although we're stuck with
>> possible run-time problems when numpy is built with the newer binutils
>> until the latest fenv.h changes are backported to all supported
>> versions of FreeBSD), but this code is machine-dependent, and fenv.h
>> needs to be selected based on ARCH.

Oops: it seems that the r203441 only affected amd64 and i386, so the
latest headers shouldn't be used for the other architectures (there
may be problems lurking there, too, but that's another matter).  So my
sketch should be altered to something like:


...
.if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <= 900009 && \
(${ARCH} == "i386" || ${ARCH} == "amd64")
.if ${ARCH} == "i386"
 FP_ARCH= i387
.elif ${ARCH} == "amd64"
 FP_ARCH= ${ARCH}
.endif
MASTER_SITES+= http://svn.freebsd.org/base/head/lib/msun/%SUBDIR%/:fp
MASTER_SITE_SUBDIR+= ${FP_ARCH}/:fp
 DISTFILES+= fenv.h:fp
.endif
.endif
 ...
  pre-configure:
.if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <= 900009
      ${CP} ${DISTDIR}/fenv.h
 ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
      ${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
.endif
...

But again, this probably isn't necessary if lang/gcc44 is only using
the base system binutils, and indeed may fail if lang/gcc44 was built
when devel/binutils was not installed -- so we should see first what
action will be taken regarding lang/gcc44, or use a more refined test.

b.
Comment 11 b. f. 2010-02-15 15:18:11 UTC
On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
> On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
>> On 2/15/10, b. f. <bf1783@googlemail.com> wrote:

> ...
> .if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <= 900009 && \
> (${ARCH} == "i386" || ${ARCH} == "amd64")
> .if ${ARCH} == "i386"
>  FP_ARCH= i387
> .elif ${ARCH} == "amd64"
>  FP_ARCH= ${ARCH}
> .endif
> MASTER_SITES+= http://svn.freebsd.org/base/head/lib/msun/%SUBDIR%/:fp
> MASTER_SITE_SUBDIR+= ${FP_ARCH}/:fp
>  DISTFILES+= fenv.h:fp
> .endif
> .endif
>  ...
>   pre-configure:
> .if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <= 900009

Sigh.  Test for the i386/amd64 on the above line, too, of course.


>       ${CP} ${DISTDIR}/fenv.h
>  ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
>       ${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
> .endif
> ...
Comment 12 Li-Lun Wang 2010-02-15 15:23:49 UTC
On Mon, Feb 15, 2010 at 3:11 PM, b. f. <bf1783@googlemail.com> wrote:
> On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
>> On 2/15/10, b. f. <bf1783@googlemail.com> wrote:
>>>>From: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>
>>>>To: bug-followup at FreeBSD.org
>>>>Cc:
>>>>Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
>>>>Date: Mon, 15 Feb 2010 12:50:24 +0800
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>
>>>>The following patch will fix the problem. =C2=A0It first detects if
>>>> binutils>=3D2.18.50 is installed. =C2=A0If it is, then it patches nump=
y so
>>>> that the new fenv.h will be used if __FreeBSD_version <=3D 900009.
>>>
>>> This fixes the build problem on i386 (although we're stuck with
>>> possible run-time problems when numpy is built with the newer binutils
>>> until the latest fenv.h changes are backported to all supported
>>> versions of FreeBSD), but this code is machine-dependent, and fenv.h
>>> needs to be selected based on ARCH.
>
> Oops: it seems that the r203441 only affected amd64 and i386, so the
> latest headers shouldn't be used for the other architectures (there
> may be problems lurking there, too, but that's another matter). =C2=A0So =
my
> sketch should be altered to something like:
>
>
> ...
> .if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <=3D 900009 && \
> (${ARCH} =3D=3D "i386" || ${ARCH} =3D=3D "amd64")
> .if ${ARCH} =3D=3D "i386"
> =C2=A0FP_ARCH=3D i387
> .elif ${ARCH} =3D=3D "amd64"
> =C2=A0FP_ARCH=3D ${ARCH}
> .endif
> MASTER_SITES+=3D http://svn.freebsd.org/base/head/lib/msun/%SUBDIR%/:fp
> MASTER_SITE_SUBDIR+=3D ${FP_ARCH}/:fp
> =C2=A0DISTFILES+=3D fenv.h:fp
> .endif
> .endif
> =C2=A0...
> =C2=A0pre-configure:
> .if exists(${LOCALBASE}/bin/as) && ${OSVERSION} <=3D 900009
> =C2=A0 =C2=A0 =C2=A0${CP} ${DISTDIR}/fenv.h
> =C2=A0${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
> =C2=A0 =C2=A0 =C2=A0${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch;=
 \
> .endif
> ...
>
> But again, this probably isn't necessary if lang/gcc44 is only using
> the base system binutils, and indeed may fail if lang/gcc44 was built
> when devel/binutils was not installed -- so we should see first what
> action will be taken regarding lang/gcc44, or use a more refined test.

I agree.  This really isn't a bug in the numpy port, but the
unfortunate result of devel/binutils and bug in fenv.h.  Fixing in the
numpy side is more of just a hack to make it build.

-- llwang
Comment 13 gerald 2010-02-15 20:41:17 UTC
On Mon, 15 Feb 2010, b. f. wrote:
> This problem is occurring with lang/gcc44 from Ports, when
> devel/binutils is installed, because then the latest gcc44 snapshots
> are automatically preferring devel/binutils to the base system
> binutils.

No-no.  lang/gcc44 does not "automatically" prefer things.  I just 
verified that.

What you describe only happens when an admin _willfully_ selects
the tools from devel/binutils over the system ones.  I assume in
this case this happened by setting PATH accordingly, though there
are other ways.  And of course, when someone arbitrarily replaces
system tools by others, or even just newer versions, all sorts of
unforeseen things can happen.


The proposed patch to check for the version of devel/binutils is
not correct, since it is not granted that lang/gcc44 would use that
version of binutils.  For example, as b.f. notices, we could force
it to use the system tools even when devel/binutils is installed.
You may want to use '$CC -print-prog-name=as' to identify the
version of as that GCC is using and go from there.


That said, given the increasing problems that are arising due to
the rotten binutils that are in the base system, I had planned to
also have lang/gcc44 use devel/binutils for a while, after seeing
how this pans out with lang/gcc45.  I am testing a patch to that
end right now and plan to commit it within the next 24 hours, when
I will also update to the latest snapshot of GCC 4.4.

Still, as far as math/py-numpy goes, please do check for the
version of binutils that is used by GCC instead of hardcoding
things.  For example, if we later make this an OPTION, things
could break again otherwise.

Gerald
Comment 14 b. f. 2010-02-16 03:10:09 UTC
On 2/15/10, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Mon, 15 Feb 2010, b. f. wrote:
>> This problem is occurring with lang/gcc44 from Ports, when
>> devel/binutils is installed, because then the latest gcc44 snapshots
>> are automatically preferring devel/binutils to the base system
>> binutils.
>
> No-no.  lang/gcc44 does not "automatically" prefer things.  I just
> verified that.
>
> What you describe only happens when an admin _willfully_ selects
> the tools from devel/binutils over the system ones.

How did you verify it?  I find that lang/gcc44 does prefer
devel/binutils: I installed devel/binutils in /usr/local, and then
built and installed lang/gcc44 (version 4.4.4.20100209) into the same
prefix on 9-CURRENT amd64, without any local modifications to included
Makefiles or the build environment.  The resulting binaries show:

#gcc44 -print-prog-name=as
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.4/../../../../../x86_64-portbld-freebsd9.0/bin/as
# gcc44 -print-prog-name=ar
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.4/../../../../../x86_64-portbld-freebsd9.0/bin/ar

and so on, where:

# pkg_info -W /usr/local//x86_64-portbld-freebsd9.0/bin/as
/usr/local/x86_64-portbld-freebsd9.0/bin/as was installed by package
binutils-2.20

This agrees with:

http://gcc.gnu.org/install/configure.html

where it states:

'--with-as=pathname

"Specify that the compiler should use the assembler pointed to by
pathname, rather than the one found by the standard rules to find an
assembler, which are:

Unless GCC is being built with a cross compiler, check the
libexec/gcc/target/version directory. libexec defaults to
exec-prefix/libexec; exec-prefix defaults to prefix, which defaults to
/usr/local unless overridden by the --prefix=pathname switch described
above. target is the target system triple, such as
`sparc-sun-solaris2.7', and version denotes the GCC version, such as
3.0.
If the target system is the same that you are building on, check
operating system specific directories (e.g. /usr/ccs/bin on Sun
Solaris 2).
Check in the PATH for a tool whose name is prefixed by the target
system triple.
Check in the PATH for a tool whose name is not prefixed by the target
system triple, if the host and target system triple are the same (in
other words, we use a host tool if it can be used for the target as
well)." '

Note that the tool whose name is prefixed by the target system triple,
in this case,
x86_64-portbld-freebsd9.0, takes precedence over a tool whose name is
not prefixed by the target system triple.

When devel/binutils is not installed, the result is different: see the
attached diff contrasting the outcomes of the configure targets in
each case.

With lang/gcc45, when the AR, AS, LD, etc. are specified as
/usr/local/bin/ar, etc., and the CONFIGURE_ARGS
--with-build-time-tools=/usr/local/bin, --with-as=/usr/local/bin/as,
etc. are issued, then all of the tools are found as /usr/local/bin/ar,
etc., as expected. Presumably this would also work for lang/gcc44,
enabling the binutils to be fixed.

b.
Comment 15 Li-Lun Wang 2010-02-16 04:26:56 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Please take a look at the following patch.  I hope it addresses all of
the concerns mentioned so far.  I had too much fun with the version
strings of as.  Hopefully there wouldn't be yet another format for the
version string.

diff -urN py-numpy.orig/Makefile py-numpy/Makefile
- --- py-numpy.orig/Makefile	2010-02-07 12:08:47.306031963 -0600
+++ py-numpy/Makefile	2010-02-15 22:12:23.719903465 -0600
@@ -33,6 +33,16 @@
 
 .include <bsd.port.pre.mk>
 
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+MASTER_SITES+=	http://svn.freebsd.org/base/head/lib/msun/:fp
+.if ${ARCH} == "i386"
+FP_ARCH=	i387
+.elif ${ARCH} == "amd64"
+FP_ARCH=	${ARCH}
+.endif
+DISTFILES+=	${FP_ARCH}/fenv.c?p=203441:fp ${FP_ARCH}/fenv.h?p=203441:fp
+.endif
+
 .if defined(WITH_ATLAS)
 LIB_DEPENDS+=	atlas.2:${PORTSDIR}/math/atlas
 .if !exists(${LOCALBASE}/lib/libalapack.a)
@@ -59,6 +69,14 @@
 
 GCCLIBDIR=	`${FC} -print-file-name=libgfortran.so|${SED} -e s/libgfortran.so//`
 pre-configure:
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${CP} ${DISTDIR}/${FP_ARCH}/fenv.c?p=203441 ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c; \
+		${CP} ${DISTDIR}/${FP_ARCH}/fenv.h?p=203441 ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
+		${REINPLACE_CMD} -e 's|<fenv.h>|"fenv.h"|' ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c; \
+		${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
+ 	fi
+.endif
 .ifdef WITH_ATLAS
 	@${REINPLACE_CMD} -e "s+%%GCCLIBDIR%%+${GCCLIBDIR}+" \
 	    -e "s+%%LOCALBASE%%+${LOCALBASE}+g" \
@@ -72,11 +90,25 @@
 .endif
 	@${REINPLACE_CMD} -e "s+%%GCCLIBDIR%%+${GCCLIBDIR}+" ${WRKSRC}/numpy/distutils/system_info.py
 
+pre-install:
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${RM} ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c.bak; \
+	fi
+.endif
+
 post-install:
 	${INSTALL_MAN} ${WRKSRC}/numpy/f2py/f2py.1 ${MAN1PREFIX}/man/man1
 .if !defined(NOPORTDOCS)
 	@${MKDIR} ${DOCSDIR}
 	${INSTALL_DATA} ${WRKDIR}/numpybook.pdf ${DOCSDIR}
 .endif
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${REINPLACE_CMD} -e "s|%%FENV%%||g" ${TMPPLIST}; \
+	else \
+		${REINPLACE_CMD} -e "s|%%FENV%%|@comment |g" ${TMPPLIST}; \
+	fi
+.endif
 
 .include <bsd.port.post.mk>
diff -urN py-numpy.orig/distinfo py-numpy/distinfo
- --- py-numpy.orig/distinfo	2010-02-07 12:08:47.346034919 -0600
+++ py-numpy/distinfo	2010-02-15 19:51:49.134852482 -0600
@@ -4,3 +4,15 @@
 MD5 (numpybook.pdf) = 637180cd704dc8be4036c09412501397
 SHA256 (numpybook.pdf) = 8c9692db7373838c585073e4141ae4bd3b8793dffd59ce3544bf851e71e9b865
 SIZE (numpybook.pdf) = 2148630
+MD5 (i387/fenv.c?p=203441) = d371542b4c2d17088d52f73862726496
+SHA256 (i387/fenv.c?p=203441) = c7c558ddb6ab6604c83062fe0655d3ce8cf4d60edb4c9c82777962c49d23ca54
+SIZE (i387/fenv.c?p=203441) = 4791
+MD5 (i387/fenv.h?p=203441) = d7c13d3c58b762a7a8814e7d6c585689
+SHA256 (i387/fenv.h?p=203441) = 40c72f3cdd6990076394056e06461e1daeb6087b6a32f1962d3c33b0a00c0e0d
+SIZE (i387/fenv.h?p=203441) = 6774
+MD5 (amd64/fenv.c?p=203441) = be35d718bd9113d9efa6fc777298d12d
+SHA256 (amd64/fenv.c?p=203441) = 9741a9ad3f8406f8292a268b0bc288dc7cb042e3e102440696d48c9a8b7955f0
+SIZE (amd64/fenv.c?p=203441) = 3601
+MD5 (amd64/fenv.h?p=203441) = 564a4e973990e4f66a5b3ab0e5ded5e1
+SHA256 (amd64/fenv.h?p=203441) = 2daf607fea1bf7e8de5e174599d963fc3bbbe48e293cf2ff08e221351472c9d6
+SIZE (amd64/fenv.h?p=203441) = 5810
diff -urN py-numpy.orig/files/fenv.patch py-numpy/files/fenv.patch
- --- py-numpy.orig/files/fenv.patch	1969-12-31 18:00:00.000000000 -0600
+++ py-numpy/files/fenv.patch	2010-02-15 19:01:10.775996010 -0600
@@ -0,0 +1,40 @@
+--- numpy/core/include/numpy/ufuncobject.h.orig	2009-12-15 06:47:53.000000000 -0600
++++ numpy/core/include/numpy/ufuncobject.h	2010-02-15 18:54:28.490863602 -0600
+@@ -306,7 +306,11 @@
+ #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(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "fenv/fenv.c"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "fenv/fenv.c"
+ #endif
+--- numpy/numarray/_capi.c.orig	2009-12-28 08:00:09.000000000 -0600
++++ numpy/numarray/_capi.c	2010-02-15 18:57:25.993127759 -0600
+@@ -9,7 +9,12 @@
+ #endif
+ 
+ #if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__) || (defined(__FreeBSD__) && (__FreeBSD_version >= 502114))
++#if defined(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "numpy/fenv/fenv.h"
++#include "numpy/fenv/fenv.c"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "numpy/fenv/fenv.h"
+ #include "numpy/fenv/fenv.c"
+--- numpy/core/setup.py.orig	2009-12-28 08:00:09.000000000 -0600
++++ numpy/core/setup.py	2010-02-15 19:00:44.715666850 -0600
+@@ -625,7 +625,7 @@
+             ]
+ 
+     # Don't install fenv unless we need them.
+-    if sys.platform == 'cygwin':
++    if sys.platform == 'cygwin' or sys.platform.startswith('freebsd'):
+         config.add_data_dir('include/numpy/fenv')
+ 
+     config.add_extension('_sort',
diff -urN py-numpy.orig/pkg-plist py-numpy/pkg-plist
- --- py-numpy.orig/pkg-plist	2010-02-07 12:08:47.366021172 -0600
+++ py-numpy/pkg-plist	2010-02-15 21:23:46.322187473 -0600
@@ -64,6 +64,8 @@
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/_numpyconfig.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/arrayobject.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/arrayscalars.h
+%%FENV%%%%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv/fenv.c
+%%FENV%%%%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv/fenv.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/multiarray_api.txt
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/ndarrayobject.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/noprefix.h
@@ -966,6 +968,7 @@
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/tests
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/lib/npy-pkg-config
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/lib
+%%FENV%%@dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iD8DBQFLeh6OCQM7t5B2mhARAtIoAJ0Ta2RLjhYsEpk6/m64g/l5KbuoegCeKYkk
UtCn8bYFiOJWrdsfJYSYlV0=
=to7p
-----END PGP SIGNATURE-----
Comment 16 Li-Lun Wang 2010-02-17 22:31:59 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I forgot to substitute the %%FENV%% in plist in one case.  The
following is the updated patch.

diff -urN py-numpy.orig/Makefile py-numpy/Makefile
- --- py-numpy.orig/Makefile	2010-02-07 12:08:47.306031963 -0600
+++ py-numpy/Makefile	2010-02-17 16:28:10.471278208 -0600
@@ -33,6 +33,16 @@
 
 .include <bsd.port.pre.mk>
 
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+MASTER_SITES+=	http://svn.freebsd.org/base/head/lib/msun/:fp
+.if ${ARCH} == "i386"
+FP_ARCH=	i387
+.elif ${ARCH} == "amd64"
+FP_ARCH=	${ARCH}
+.endif
+DISTFILES+=	${FP_ARCH}/fenv.c?p=203441:fp ${FP_ARCH}/fenv.h?p=203441:fp
+.endif
+
 .if defined(WITH_ATLAS)
 LIB_DEPENDS+=	atlas.2:${PORTSDIR}/math/atlas
 .if !exists(${LOCALBASE}/lib/libalapack.a)
@@ -59,6 +69,14 @@
 
 GCCLIBDIR=	`${FC} -print-file-name=libgfortran.so|${SED} -e s/libgfortran.so//`
 pre-configure:
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${CP} ${DISTDIR}/${FP_ARCH}/fenv.c?p=203441 ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c; \
+		${CP} ${DISTDIR}/${FP_ARCH}/fenv.h?p=203441 ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.h; \
+		${REINPLACE_CMD} -e 's|<fenv.h>|"fenv.h"|' ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c; \
+		${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/fenv.patch; \
+ 	fi
+.endif
 .ifdef WITH_ATLAS
 	@${REINPLACE_CMD} -e "s+%%GCCLIBDIR%%+${GCCLIBDIR}+" \
 	    -e "s+%%LOCALBASE%%+${LOCALBASE}+g" \
@@ -72,11 +90,27 @@
 .endif
 	@${REINPLACE_CMD} -e "s+%%GCCLIBDIR%%+${GCCLIBDIR}+" ${WRKSRC}/numpy/distutils/system_info.py
 
+pre-install:
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${RM} ${WRKSRC}/numpy/core/include/numpy/fenv/fenv.c.bak; \
+	fi
+.endif
+
 post-install:
 	${INSTALL_MAN} ${WRKSRC}/numpy/f2py/f2py.1 ${MAN1PREFIX}/man/man1
 .if !defined(NOPORTDOCS)
 	@${MKDIR} ${DOCSDIR}
 	${INSTALL_DATA} ${WRKDIR}/numpybook.pdf ${DOCSDIR}
 .endif
+.if ${OSVERSION} <= 900009 && (${ARCH} == "i386" || ${ARCH} == "amd64")
+	@if [ "`${PKG_VERSION} -t \"\`\\\`${CC} -print-prog-name=as\\\` --version | ${AWK} 'NR==1 {sub(/\(GNU Binutils\)/,""); print $$3}'\`\" 2.18.49`" = ">" ] ; then \
+		${REINPLACE_CMD} -e "s|%%FENV%%||g" ${TMPPLIST}; \
+	else \
+		${REINPLACE_CMD} -e "s|%%FENV%%|@comment |g" ${TMPPLIST}; \
+	fi
+.else
+	@${REINPLACE_CMD} -e "s|%%FENV%%|@comment |g" ${TMPPLIST}
+.endif
 
 .include <bsd.port.post.mk>
diff -urN py-numpy.orig/distinfo py-numpy/distinfo
- --- py-numpy.orig/distinfo	2010-02-07 12:08:47.346034919 -0600
+++ py-numpy/distinfo	2010-02-15 19:51:49.134852482 -0600
@@ -4,3 +4,15 @@
 MD5 (numpybook.pdf) = 637180cd704dc8be4036c09412501397
 SHA256 (numpybook.pdf) = 8c9692db7373838c585073e4141ae4bd3b8793dffd59ce3544bf851e71e9b865
 SIZE (numpybook.pdf) = 2148630
+MD5 (i387/fenv.c?p=203441) = d371542b4c2d17088d52f73862726496
+SHA256 (i387/fenv.c?p=203441) = c7c558ddb6ab6604c83062fe0655d3ce8cf4d60edb4c9c82777962c49d23ca54
+SIZE (i387/fenv.c?p=203441) = 4791
+MD5 (i387/fenv.h?p=203441) = d7c13d3c58b762a7a8814e7d6c585689
+SHA256 (i387/fenv.h?p=203441) = 40c72f3cdd6990076394056e06461e1daeb6087b6a32f1962d3c33b0a00c0e0d
+SIZE (i387/fenv.h?p=203441) = 6774
+MD5 (amd64/fenv.c?p=203441) = be35d718bd9113d9efa6fc777298d12d
+SHA256 (amd64/fenv.c?p=203441) = 9741a9ad3f8406f8292a268b0bc288dc7cb042e3e102440696d48c9a8b7955f0
+SIZE (amd64/fenv.c?p=203441) = 3601
+MD5 (amd64/fenv.h?p=203441) = 564a4e973990e4f66a5b3ab0e5ded5e1
+SHA256 (amd64/fenv.h?p=203441) = 2daf607fea1bf7e8de5e174599d963fc3bbbe48e293cf2ff08e221351472c9d6
+SIZE (amd64/fenv.h?p=203441) = 5810
diff -urN py-numpy.orig/files/fenv.patch py-numpy/files/fenv.patch
- --- py-numpy.orig/files/fenv.patch	1969-12-31 18:00:00.000000000 -0600
+++ py-numpy/files/fenv.patch	2010-02-15 19:01:10.775996010 -0600
@@ -0,0 +1,40 @@
+--- numpy/core/include/numpy/ufuncobject.h.orig	2009-12-15 06:47:53.000000000 -0600
++++ numpy/core/include/numpy/ufuncobject.h	2010-02-15 18:54:28.490863602 -0600
+@@ -306,7 +306,11 @@
+ #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(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "fenv/fenv.c"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "fenv/fenv.c"
+ #endif
+--- numpy/numarray/_capi.c.orig	2009-12-28 08:00:09.000000000 -0600
++++ numpy/numarray/_capi.c	2010-02-15 18:57:25.993127759 -0600
+@@ -9,7 +9,12 @@
+ #endif
+ 
+ #if defined(__GLIBC__) || defined(__APPLE__) || defined(__MINGW32__) || (defined(__FreeBSD__) && (__FreeBSD_version >= 502114))
++#if defined(__FreeBSD__) && (__FreeBSD_version <= 900009)
++#include "numpy/fenv/fenv.h"
++#include "numpy/fenv/fenv.c"
++#else
+ #include <fenv.h>
++#endif
+ #elif defined(__CYGWIN__)
+ #include "numpy/fenv/fenv.h"
+ #include "numpy/fenv/fenv.c"
+--- numpy/core/setup.py.orig	2009-12-28 08:00:09.000000000 -0600
++++ numpy/core/setup.py	2010-02-15 19:00:44.715666850 -0600
+@@ -625,7 +625,7 @@
+             ]
+ 
+     # Don't install fenv unless we need them.
+-    if sys.platform == 'cygwin':
++    if sys.platform == 'cygwin' or sys.platform.startswith('freebsd'):
+         config.add_data_dir('include/numpy/fenv')
+ 
+     config.add_extension('_sort',
diff -urN py-numpy.orig/pkg-plist py-numpy/pkg-plist
- --- py-numpy.orig/pkg-plist	2010-02-07 12:08:47.366021172 -0600
+++ py-numpy/pkg-plist	2010-02-15 21:23:46.322187473 -0600
@@ -64,6 +64,8 @@
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/_numpyconfig.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/arrayobject.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/arrayscalars.h
+%%FENV%%%%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv/fenv.c
+%%FENV%%%%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv/fenv.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/multiarray_api.txt
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/ndarrayobject.h
 %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/noprefix.h
@@ -966,6 +968,7 @@
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/tests
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/lib/npy-pkg-config
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/lib
+%%FENV%%@dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy/fenv
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include/numpy
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core/include
 @dirrm %%PYTHON_SITELIBDIR%%/numpy/core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iD8DBQFLfG5dCQM7t5B2mhARAlXgAJ9oDC4jSXmtikkbaZx3GTS1YAhqJACdFGQb
eOdjZ0ANVyp31EGsuWvI4/c=
=ZubZ
-----END PGP SIGNATURE-----
Comment 17 Dmitry Sivachenko freebsd_committer freebsd_triage 2010-03-12 12:55:49 UTC
State Changed
From-To: feedback->closed

I committed the last patch from this thread (patch-5.diff). 
It appears to work on my 7-/8-STABLE machines.
Comment 18 gerald 2010-09-12 13:21:09 UTC
On Mon, 15 Feb 2010, b. f. wrote:
>>> This problem is occurring with lang/gcc44 from Ports, when 
>>> devel/binutils is installed, because then the latest gcc44 snapshots 
>>> are automatically preferring devel/binutils to the base system 
>>> binutils.
>> No-no.  lang/gcc44 does not "automatically" prefer things.  I just
>> verified that.
>>
>> What you describe only happens when an admin _willfully_ selects
>> the tools from devel/binutils over the system ones.
> How did you verify it?  I find that lang/gcc44 does prefer
> devel/binutils: I installed devel/binutils in /usr/local, and then
> built and installed lang/gcc44 (version 4.4.4.20100209) into the same
> prefix on 9-CURRENT amd64, without any local modifications to included
> Makefiles or the build environment.  The resulting binaries show:

One thing I forgot to mention is that partly in reaction to this report
lang/gcc44 is now unconditionally using devel/binutils since mid February,
as lang/gcc45 had been doing before.

Also, I am in the process of moving USE_FORTRAN=yes from GCC 4.4 to
GCC 4.5 and expect that the later will gradually become the "default"
version of USE_GCC.

Gerald