On Tue, Mar 10 2020, Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
> On Mon, Mar 09 2020, Stuart Henderson <stu@spacehopper.org> wrote:
>> On 2020/03/09 10:42, Theo Buehler wrote:
>>> On Mon, Jan 13, 2020 at 12:50:32PM +0000, Stuart Henderson wrote:
>>> > 2/3 through a bulk build and I see that this breaks scipy (missing symbols,
>>> > blas/cblas-related) so needs a bit more work, but I think it's generally
>>> > along the right lines.
>>>
>>> Not sure if this provides any useful clue, but py-numpy doesn't build at
>>> all on sparc64 with this diff, also due to missing blas/cblas symbols:
>>
>> You'll probably see the same on amd64 with USE_LLD=no.
>
> I managed to build scipy with no changes on amd64, so I'm not sure what
> the problem is on this arch (did not try with USE_LLD=No).
>
> However I took a look at the issue reported by tb on sparc64.
>
> --8<--
> creating /tmp/tmpKcZ0cd/tmp
> creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
> compile options: '-I/usr/local/include -I/usr/include -c'
> cc: /tmp/tmpKcZ0cd/source.c
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o /tmp/tmpKcZ0cd/a.out
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
>
> [...]
>
> /usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
> collect2: error: ld returned 1 exit status
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o /tmp/tmpKcZ0cd/a.out
> /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
> source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
> -->8--
>
> libcblas.so doesn't depend on libblas.so so missing symbols are to be
> expected if one links with -lcblas instead of -lcblas -lblas. The
> second linking test fails because libblas.so doesn't provide cblas
> symbols.
>
> I think the way forward is to make libcblas.so depend on libblas.so
> (this is what you get eg on Debian). It would probably make sense to do
> the same with lapack.
>
> With the following cblas diff I can build py-numpy-1.16.5 on amd64 and
> sparc64. cc'ing Steven.
>
> ok?
Here's an updated diff for numpy-1.16.5, for convenience I decided to
drop the hard requirements I had on cblas>=1.1 (WANTLIB) /
math/cblas>=1.0p7 (LIB_DEPENDS).
Index: Makefile
===================================================================
RCS file: /cvs/ports/math/py-numpy/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- Makefile 10 Mar 2020 03:31:45 -0000 1.57
+++ Makefile 10 Mar 2020 17:06:13 -0000
@@ -2,11 +2,10 @@
COMMENT= fast array and numeric programming library for Python
-MODPY_EGG_VERSION= 1.14.6
+MODPY_EGG_VERSION= 1.16.5
DISTNAME= numpy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
EXTRACT_SUFX= .zip
-REVISION= 2
CATEGORIES= math devel
@@ -15,7 +14,8 @@ HOMEPAGE= https://www.numpy.org/
# BSD
PERMIT_PACKAGE = Yes
-WANTLIB= blas lapack m pthread ${MODFORTRAN_WANTLIB} ${MODPY_WANTLIB}
+WANTLIB += ${MODFORTRAN_WANTLIB} ${MODPY_WANTLIB}
+WANTLIB += blas cblas lapack m pthread
MODULES= lang/python \
fortran
@@ -27,13 +27,14 @@ MODPY_PI = Yes
MODPY_SETUPTOOLS= Yes
MODPY_DISTUTILS_BUILDARGS = --fcompiler=gnu95
-TEST_DEPENDS= devel/py-nose${MODPY_FLAVOR} \
- devel/py-tz${MODPY_FLAVOR}
-
+TEST_DEPENDS= ${FULLPKGNAME}:${FULLPKGPATH} \
+ devel/py-test${MODPY_FLAVOR} \
+ devel/py-tz${MODPY_FLAVOR}
MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS = ${MODFORTRAN_BUILD_DEPENDS}
-LIB_DEPENDS= math/lapack \
+LIB_DEPENDS= math/cblas \
+ math/lapack \
${MODFORTRAN_LIB_DEPENDS}
# Cython 0.28.* uses __attribute__((optimize("Os"))) which
Index: distinfo
===================================================================
RCS file: /cvs/ports/math/py-numpy/distinfo,v
retrieving revision 1.13
diff -u -p -r1.13 distinfo
--- distinfo 26 Oct 2018 21:09:31 -0000 1.13
+++ distinfo 10 Mar 2020 17:06:13 -0000
@@ -1,2 +1,2 @@
-SHA256 (numpy-1.14.6.zip) = ElDt9vbEPh14I/CWdBa8GCWLsnHcU2KY6w6gCp5FuAo=
-SIZE (numpy-1.14.6.zip) = 4906096
+SHA256 (numpy-1.16.5.zip) = i7RS2U6WSzEiBbDeEjjdcgnaRSNDZTqyFLXWgXgOegw=
+SIZE (numpy-1.16.5.zip) = 5138208
Index: patches/patch-numpy_core_include_numpy_npy_common_h
===================================================================
RCS file: /cvs/ports/math/py-numpy/patches/patch-numpy_core_include_numpy_npy_common_h,v
retrieving revision 1.6
diff -u -p -r1.6 patch-numpy_core_include_numpy_npy_common_h
--- patches/patch-numpy_core_include_numpy_npy_common_h 30 Jun 2018 21:49:33 -0000 1.6
+++ patches/patch-numpy_core_include_numpy_npy_common_h 10 Mar 2020 17:06:13 -0000
@@ -1,13 +1,8 @@
$OpenBSD: patch-numpy_core_include_numpy_npy_common_h,v 1.6 2018/06/30 21:49:33 daniel Exp $
-(1) optimize function attributes were added in gcc 4.4. Apply a fix for the warnings. But
-the next release of numpy should fix this in a better way. See:
-https://github.com/numpy/numpy/issues/5451
+XXX recheck powerpc, is this still needed?
-Gets rid of these warnings from the build:
-numpy/core/src/multiarray/lowlevel_strided_loops.c.src:120: warning: 'optimize' attribute directive ignored
-
-(2) py-numpy only checks for expl to determine whether extended-precision
+py-numpy only checks for expl to determine whether extended-precision
support is present. since we don't have it yet; it implements
it's own. however, on alpha, powerpc, it declared functions with
types that conflict with C99 (double for *l), therefore failed.
@@ -15,36 +10,7 @@ types that conflict with C99 (double for
Index: numpy/core/include/numpy/npy_common.h
--- numpy/core/include/numpy/npy_common.h.orig
+++ numpy/core/include/numpy/npy_common.h
-@@ -20,6 +20,7 @@
-
No comments:
Post a Comment