py26-numpy @1.5.0 shell command failed

[josharian@…]

Update py26-numpy to @1.5.0 from @1.4.1 fails on my 10.6.4 machine. Compilation log is attached. Not sure what further info I should provide -- please advise.

[jmroot (Joshua Root)]

Please remember to cc the maintainer.

[jmroot (Joshua Root)]

Duplicate of #24942.

[josharian@…]

Re: ccing the maintainer: This is my first ticket, but thanks for the heads up. Will do.

Re: dup of #24942 -- perhaps I'm missing something, but if that were it, wouldn't I have been unable to install 1.4.1 successfully in the first place?

[grenander@…]

I have the same issue. I am not sure how to resolve it using #24942. I have numpy 1.4.1 linked to Macports atlas, can I not do the same with numpy 1.5?

Downloading source and building manually works but it uses the OS's BLAS, LAPACK. Corresponding lines:

creating build/temp.macosx-10.6-x86_64-2.6/numpy/linalg
compile options: '-DNO_ATLAS_INFO=3 -Inumpy/core/include -Ibuild/src.macosx-10.6-x86_64-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/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -Ibuild/src.macosx-10.6-x86_64-2.6/numpy/core/src/multiarray -Ibuild/src.macosx-10.6-x86_64-2.6/numpy/core/src/umath -c'
extra options: '-faltivec'
gcc-4.2: numpy/linalg/python_xerbla.c
gcc-4.2: numpy/linalg/lapack_litemodule.c
/usr/bin/gcc-4.2 -L/opt/local/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.6-x86_64-2.6/numpy/linalg/lapack_litemodule.o build/temp.macosx-10.6-x86_64-2.6/numpy/linalg/python_xerbla.o -Lbuild/temp.macosx-10.6-x86_64-2.6 -o build/lib.macosx-10.6-x86_64-2.6/numpy/linalg/lapack_lite.so -Wl,-framework -Wl,Accelerate

[grenander@…]

Cc Me!

[ajb78@…]

Cc Me!

[ajb78@…]

I have the same problem. I also seemed to be able to compile numpy 1.4.1 against atlas, but not 1.5.0.

[cdeil (Christoph Deil)]

Same problem and I also cannot resolve the problem using ticket #24942.

[cdeil (Christoph Deil)]

Cc Me!

[jmroot (Joshua Root)]

That's why the original ticket is still open.

[ajb78@…]

The original ticket is for numpy 1.4.1 and is labeled as such. I can confirm that revision 1 of this port did in fact compile for me atlas support on my machine.

This issue with numpy 1.5.0. I can also confirm that this version does not compile with atlas support on my machine.

Given the version bump, and the fact that for at least some people this problem does not appear with 1.4.1 but does with 1.5.0, I do think that might be a different issue.

[sean@…]

Cc Me!

[marshall.ward@…]

numpy 1.4.1 installs and works for me without issue. Numpy 1.5.0 simply won't install. If this is related to ticket #24942, then the issue is more subtle than a simple duplicate. Numpy 1.5.0 was modified for python 3 compatibility, so surely some new issue arising from integration with atlas could have emerged?

[marshall.ward@…]

Cc Me!

[cdeil (Christoph Deil)]

I agree with Marshall and ajb78, I think this is a new problem.

[jschwab@…]

Cc Me!

[Veence (Vincent)]

Replying to marshall.ward@…:

numpy 1.4.1 installs and works for me without issue. Numpy 1.5.0 simply won't install. If this is related to ticket #24942, then the issue is more subtle than a simple duplicate. Numpy 1.5.0 was modified for python 3 compatibility, so surely some new issue arising from integration with atlas could have emerged?

The final link lacks a -lpython26 option.

[michaelld (Michael Dickens)]

Linking with -lpython will cause Python to crash when "import numpy" is issued. The final link lacks "-undefined dynamic_lookup -bundle" (the usual value for LDFLAGS for this module's linking), which happens when LDFLAGS is set to anything (including "") during build. There's a simple patch to this library's setup.py script to fix this issue & allow for whatever LDFLAGS are provided externally. BUT: I think we can get away without even using LDFLAGS, so this patch won't be necessary.

[Veence (Vincent)]

I can't reproduce this bug. For me, it works, but the link is not made with gfortran, but with gcc-4.2. I will dig a bit further if deemed necessary.

[michaelld (Michael Dickens)]

I think the OP's command was (effectively) "sudo port install py26-numpy +gcc44 +universal". For me (10.6.4 x86_64 native, XCode 3.2.3, MacPorts 1.9.1.99 latest from SVN), this command results in the same as what's posted.

The fix, for me, is to remove all of the GCC variants (so lines 44-47) and thus change the command to "sudo port install py26-numpy +universal". This is one of possibly a few math-oriented ports that do not directly require linking to libgcc or libgfortran, so removing those variants should be safe.

I would encourage those on this ticket to try out this fix & see if it works for them, with and without +universal if possible.

[jmroot (Joshua Root)]

Replying to marshall.ward@…:

numpy 1.4.1 installs and works for me without issue. Numpy 1.5.0 simply won't install.

So you built 1.4.1 after having 1.5.0 fail in order to rule out a configuration change? This problem is clearly configuration dependent because a lot of people have never seen it with either version.

[marshall.ward@…]

Replying to jmr@…:

So you built 1.4.1 after having 1.5.0 fail in order to rule out a configuration change? This problem is clearly configuration dependent because a lot of people have never seen it with either version.

Sorry if it wasn't clear. Numpy 1.4.1 built using atlas and without any issues, and I've been using it for several months. The issue didn't appear until I tried upgrading to 1.5.0.

[marshall.ward@…]

If numpy 1.4.1 builds properly but numpy 1.5.0 is unable to build, could it be the same issue as #24942? Both are failing to link to lapack_lite. Is it just a configuration problem somewhere down the chain? I am willing to look into it more m

[josharian@…]

I think the OP's command was (effectively) "sudo port install py26-numpy +gcc44 +universal". For me (10.6.4 x86_64 native, XCode 3.2.3, MacPorts 1.9.1.99 latest from SVN), this command results in the same as what's posted.

Actually, I think the only variant was +gcc44. Also (in case it matters), I am upgrading from 1.4.1, which built fine some time ago, and the +gcc44 flag was (I believe) inherited from py26-scipy; numpy was installed as a dependency.

The fix, for me, is to remove all of the GCC variants (so lines 44-47) and thus change the command to "sudo port install py26-numpy +universal". This is one of possibly a few math-oriented ports that do not directly require linking to libgcc or libgfortran, so removing those variants should be safe. I would encourage those on this ticket to try out this fix & see if it works for them, with and without +universal if possible.

sudo port clean py26-numpy sudo port build py26-numpy -gcc44

yields exactly the same set of errors as before. Is the right set of commands to try out your suggestion (without fear of hosing my current functioning 1.4.1 install)?

[michaelld (Michael Dickens)]

I'm moving my comments & patches to ticket #24942. Please go there & try them out.