--- 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
Responsible Changed From-To: freebsd-ports-bugs->freebsd-python freebsd-python@ wants this port PRs (via the GNATS Auto Assign Tool)
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
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
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.
-----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-----
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.
-----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-----
>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 ...
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.
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.
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 > ...
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
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
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.
-----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-----
-----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-----
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.
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