David Cournapeau writes:

Did you make sure to build from scratch and clean the working directory first ?

I don't see the error on my macbook: umath.so has npy_cexp* functions defined.

David

Yeah, here is my build script -- it removes the build directory entirely: #!/bin/sh export MACOSX_DEPLOYMENT_TARGET=10.6 export CFLAGS="-arch i386 -arch x86_64" export FFLAGS="-arch i386 -arch x86_64" export LDFLAGS="-Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64" rm -rf build python setupegg.py config_fc --fcompiler gfortran config - L/Developer/src/freetype-2.3.5 -L/Developer/src/libpng-1.2.24 build bdist_egg

David Cournapeau writes:

On Thu, Nov 12, 2009 at 6:57 AM, Chris wrote:

...

Yeah, here is my build script -- it removes the build directory entirely

Ah, that's not enough. You need to clean the working tree as well. git has the clean option for that, you can also use a quick script to do this with parsing svn st output.

I tried scrapping the whole directory and starting again. Same thing though. I do notice a bunch of configtest warnings though: gcc-4.2: _configtest.c _configtest.c:4: warning: function declaration isn’t a prototype _configtest.c: In function ‘main’: _configtest.c:5: error: size of array ‘test_array’ is negative _configtest.c:4: warning: function declaration isn’t a prototype _configtest.c: In function ‘main’: _configtest.c:5: error: size of array ‘test_array’ is negative lipo: can't open input file: /var/folders/Cp/Cp1bvHSvFwuPM0 9XVxsVF++++TI/-Tmp-//ccO4OC35.out (No such file or directory) _configtest.c:4: warning: function declaration isn’t a prototype _configtest.c: In function ‘main’: _configtest.c:5: error: size of array ‘test_array’ is negative _configtest.c:4: warning: function declaration isn’t a prototype _configtest.c: In function ‘main’: _configtest.c:5: error: size of array ‘test_array’ is negative lipo: can't open input file: /var/folders/Cp/Cp1bvHSvFwuPM09XVx sVF++++TI/-Tmp-//ccO4OC35.out (No such file or directory) C compiler: gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -pipe Not sure this has anything to do with it. Again, none of this happened until this week, and I am using the same build script as always.

David Cournapeau writes:

I am afraid I don't see where the problem may come from. I used the exact same build script as you, on the same version of mac os x, and I don't see the problem. Is there anything non standard in your environment that you can think of ?

Not that I can think of, no. Here is my env: TERM_PROGRAM=Apple_Terminal TERM=xterm-color SHELL=/bin/bash TMPDIR=/var/folders/Cp/Cp1bvHSvFwuPM09XVxsVF++++TI/-Tmp-/ Apple_PubSub_Socket_Render=/tmp/launch-o1hxIu/Render TERM_PROGRAM_VERSION=272 USER=fonnesbeck COMMAND_MODE=unix2003 SSH_AUTH_SOCK=/tmp/launch-4DXe3p/Listeners __CF_USER_TEXT_ENCODING=0x1F5:0:0 PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin: /usr/X11/bin:/opt/local/bin:/usr/local/git/bin:/usr/local/git/bin PWD=/Users/fonnesbeck EDITOR=mate_wait LANG=en_NZ.UTF-8 SHLVL=1 HOME=/Users/fonnesbeck LESS=-R LOGNAME=fonnesbeck DISPLAY=/tmp/launch-3LiwGx/:0 _GOOGLE_GILD_RUNTIME_FRAMEWORK_ABSOLUTE_PATH_= /Library/Google/Frameworks/Gild.framework _=/usr/bin/env Nothing looks out of order, but I still get the Symbol not found: _npy_cexp errors.

On Sun, Nov 29, 2009 at 10:02 AM, Chris wrote:

Chris writes:

...

Nothing looks out of order, but I still get the Symbol not found: _npy_cexp errors.

This problem still persists through rev 7803. Is there no solution for this?

The problem is that I don't see this issue at all, so I have no idea what may cause it. I again checked with your build script on my macbook, and everything works as expected. David

Charles R Harris writes:

Maybe there is a stray old file floating about somewhere.

Chris, is there a locate command for the mac? Could you track down numpy related files and make sure none are sitting in some dusty old corner?Chuck

Sorry to be a pain on this, but it has me baffled. I just deleted my entire numpy source tree and pulled it down again. I also tracked down and deleted anything related to numpy anywhere in my python path. Now, I used the following script to build numpy: #!/bin/sh export MACOSX_DEPLOYMENT_TARGET=10.6 export CFLAGS="-arch x86_64" #export FFLAGS="-arch i386 -arch x86_64" export FFLAGS="-arch x86_64" export LDFLAGS="-Wall -lgfortran -undefined dynamic_lookup -bundle -arch x86_64" rm -rf build python setup.py config -L/Users/chris/Code/freetype -L/Users/chris/Code/libpng build python setupegg.py egg_info --tag-date bdist_egg But, installing the resulting egg, then importing numpy gives: In [1]: import numpy ------------------------------------------------------------ Traceback (most recent call last): File "<ipython console>", line 1, in <module> File "/Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/__init__.py", line 132, in <module> import add_newdocs File "/Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/add_newdocs.py", line 9, in <module> from lib import add_newdoc File "/Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/lib/type_check.py", line 8, in <module> import numpy.core.numeric as _nx File "/Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/core/__init__.py", line 6, in <module> import umath ImportError: dlopen(/Library/Python/2.6/site-packages/ numpy-1.4.0.dev_20091130-py2.6-macosx-10.6-universal.egg/ numpy/core/umath.so, 2): Symbol not found: _npy_cexp Referenced from: /Library/Python/2.6/site-packages/ numpy-1.4.0.dev_20091130-py2.6-macosx-10.6-universal.egg/ numpy/core/umath.so Expected in: flat namespace in /Library/Python/2.6/site-packages/numpy-1.4.0.dev_ 20091130-py2.6-macosx-10.6-universal.egg/numpy/core/umath.so The problem is clearly in the .egg that I just built, as the filenames match. For some reason umath is not being built properly. Thanks in advance to everyone.

Here is a log form a build of svn rev 7996 with no LDFLAGS specified, as recommended by Robert. The result is the same, however. http://files.me.com/fonnesbeck/y7e9v2 cf

On Sun, Dec 13, 2009 at 00:37, David Cournapeau wrote:

On Sun, Dec 13, 2009 at 4:27 AM, Chris wrote:

...

Here is a log form a build of svn rev 7996 with no LDFLAGS specified, as recommended by Robert. The result is the same, however.

http://files.me.com/fonnesbeck/y7e9v2

I don't see any build error on this log ?

See earlier in the thread. The error occurs at runtime: import umath ImportError: dlopen(/Library/Python/2.6/site-packages/ numpy-1.4.0.dev7726-py2.6-macosx-10.6- universal.egg/numpy/core/umath.so, 2): Symbol not found : _npy_cexp Referenced from: /Library/Python/2.6/site-packages/ numpy-1.4.0.dev7726-py2.6-macosx-10.6-universal.egg/ numpy/core/umath.so Expected in: flat namespace in /Library/Python/2.6/site-packages/ numpy-1.4.0.dev7726-py2.6-macosx-10.6-universal.egg /numpy/core/umath.so -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

David Cournapeau writes:

could you show the output from nm on umath.so, to check what symbols are missing. Maybe seeing the whole list would bring something.

Here it is: http://files.me.com/fonnesbeck/6ezhy5 The symbol in question is in there, but I see that it does not have a value.

On Mon, Dec 14, 2009 at 5:29 AM, Chris wrote:

Chris writes:

...

Here it is:

http://files.me.com/fonnesbeck/6ezhy5

Sorry, that link should be:

http://files.me.com/fonnesbeck/qv8o59

Ok, so the undefined functions all indicate that the most recently implemented ones are not included. I really cannot see any other explanation that having a discrepancy between the source tree, build tree and installation. Sometimes, svn screw things up when switching between branches in my experience, so that's something to check for as well. Could you give us the generated config.h (somewhere in build/src.*/numpy/core/), just in case ? David

David Cournapeau writes:

Ok, so the undefined functions all indicate that the most recently implemented ones are not included. I really cannot see any other explanation that having a discrepancy between the source tree, build tree and installation. Sometimes, svn screw things up when switching between branches in my experience, so that's something to check for as well.

By the way, I tried building 1.4rc1 and the same thing happens.

David Cournapeau writes:

Ok, so the undefined functions all indicate that the most recently implemented ones are not included. I really cannot see any other explanation that having a discrepancy between the source tree, build tree and installation. Sometimes, svn screw things up when switching between branches in my experience, so that's something to check for as well.

Could you give us the generated config.h (somewhere in build/src.*/numpy/core/), just in case ?

Am I to assume, then, that there is no fix for this issue at this stage? I am still unable to build a working version of the software (I tried again today with a fresh checkout). Thanks, cf

On Tue, Dec 22, 2009 at 5:29 AM, Chris wrote:

David Cournapeau writes:

...

Ok, so the undefined functions all indicate that the most recently implemented ones are not included. I really cannot see any other explanation that having a discrepancy between the source tree, build tree and installation. Sometimes, svn screw things up when switching between branches in my experience, so that's something to check for as well.

Could you give us the generated config.h (somewhere in build/src.*/numpy/core/), just in case ?

Am I to assume, then, that there is no fix for this issue at this stage?

It is more that I cannot reproduce the issue, and without being able to do so, I don't see much change to solve the issue at hand. David