py27-numpy: cannot import numpy when built with atlas

[mf2k (Frank Schima)]

I'm seeing the following error on one computer running Mac OS X 10.8.2 and Xcode 4.5.2. It installs fine on the rest of my 10.8.2 Macs but something is different about this one.

$ port installed py27-numpy
The following ports are currently installed:
 py27-numpy @1.6.2_1+atlas+gcc47 (active)

$ which python
/opt/local/bin/python

$ python
Python 2.7.3 (default, Dec 27 2012, 09:11:40) 
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line 137, in <module>
    import add_newdocs
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py", line 9, in <module>
    from numpy.lib import add_newdoc
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py", line 13, in <module>
    from polynomial import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/polynomial.py", line 17, in <module>
    from numpy.linalg import eigvals, lstsq
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/__init__.py", line 48, in <module>
    from linalg import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/linalg.py", line 23, in <module>
    from numpy.linalg import lapack_lite
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so, 2): 
  Symbol not found: _omp_get_num_threads
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
>>> 

Let me know what other information you need to debug this.

[joergf@…]

Cc Me!

[mf2k (Frank Schima)]

I'm now seeing this on all fresh installs. Something must have changed recently to cause this problem.

[mf2k (Frank Schima)]

Update. I have isolated this to the +gcc47 variant.

[mf2k (Frank Schima)]

Another update. The problem is *not* +gcc47, but instead is due to the +atlas variant.

[sean@…]

Cc Me!

[os@…]

Same error message here, trying to rebuild numpy to use atlas. Without atlas, no problem.

[os@…]

Here's a workaround that works for me: Build both atlas and py27-numpy with -gcc47, this will make them default to gcc45. Importing numpy then works even when atlas is enabled. Currently checking whether scipy will now still build with gcc47.

[Veence (Vincent)]

What is your hardware config?

[os@…]

I'm using a MacBook Pro 13-inch, early 2011.

I just figured out that it is sufficient for the workaround to compile atlas using gcc45 (macports fetched the prebuilt package atlas-3.10.1_2+gcc45.darwin_12.x86_64.tbz2). Building numpy and scipy using gcc47 then works fine.

[beany_kelly@…]

Perhaps this should be its own ticket, but has atlas been removed from the ports database altogether?

I just uninstalled it because of encountering the problem described in this ticket, and planned to reinstall it built against gcc45. But it's no longer available via port install, and it doesn't turn up in a port search of the MacPorts site. Which leaves me kind of stuck ...

[mf2k (Frank Schima)]

You need to run selfupdate again. atlas is definitely part of macports.

Actually I think the latest version of numpy 1.7.0 fixes this problem. So I'm closing this as fixed because it works for me now.

[mf2k (Frank Schima)]

r104457

[larryv (Lawrence Velázquez)]

Replying to beany_kelly@…:

Perhaps this should be its own ticket, but has atlas been removed from the ports database altogether?

I just uninstalled it because of encountering the problem described in this ticket, and planned to reinstall it built against gcc45. But it's no longer available via port install, and it doesn't turn up in a port search of the MacPorts site. Which leaves me kind of stuck ...

Open a new ticket for it. It definitely doesn’t show up ​in the port search.

[cooljeanius (Eric Gallager)]

Cc Me!

[gorticus (Jason Mitchell)]

This lapack_lite.so, 2): Symbol not found: _omp_get_num_threads problem also causes opencv (currently 4.2.2), to silently fail to build and install the python bindings, when requested. I had this working just yesterday, but after sync'ing my ports and upgrading outdated packages, no opencv+python; so traced to this atlas/lapack issue.

[mf2k (Frank Schima)]

Apparently this is still happening sometimes. Cc'ing reporter of duplicate #38748.

[michaelld (Michael Dickens)]

I see this issue too (I cannot actually compile the latest atlas, but the issue is also with the prior version):

nm -a `port contents atlas | grep libatlas` | grep omp_get_num_threads

returns "U _omp_get_num_threads" meaning that that symbol is undefined in the library. Hence, it seems like either libatlas.a needs to statically link with ${prefix}/lib/gccXY/libgomp.a, or any project using this library needs to link with ${prefix}/lib/gccXY/libgomp.dylib or .a. Basically: this seems to be an atlas issue, not a numpy issue. Or, maybe I'm missing something?

Further

% for tf in `port contents atlas | grep /lib/`; do echo $tf; nm -a $tf | grep _omp_; done
/opt/local/lib/libatlas.a
                 U _omp_get_num_threads
                 U _omp_get_thread_num
                 U _omp_set_num_threads
                 U _omp_init_lock
                 U _omp_set_lock
                 U _omp_unset_lock
                 U _omp_set_lock
                 U _omp_unset_lock
                 U _omp_destroy_lock
/opt/local/lib/libcblas.a
/opt/local/lib/libf77blas.a
/opt/local/lib/liblapack.a
/opt/local/lib/libptcblas.a
/opt/local/lib/libptf77blas.a
/opt/local/lib/libsatlas.dylib
                 U _omp_destroy_lock
                 U _omp_get_num_threads
                 U _omp_get_thread_num
                 U _omp_init_lock
                 U _omp_set_lock
                 U _omp_set_num_threads
                 U _omp_unset_lock
/opt/local/lib/libtatlas.dylib
                 U _omp_destroy_lock
                 U _omp_get_num_threads
                 U _omp_get_thread_num
                 U _omp_init_lock
                 U _omp_set_lock
                 U _omp_set_num_threads
                 U _omp_unset_lock

so, it's primarily the lib*atlas libraries that are the issue.

[michaelld (Michael Dickens)]

I cannot get atlas +universal to work with the latest changes to the Portfile, but the x86_64 build's libraries do not have the issue I mention above (at least for me). Now, if I could get atlas i386 to work ...

[mf2k (Frank Schima)]

Cc'ing maintainer of atlas port.

[cmutel (Chris Mutel)]

Cc Me!

[jjstickel (Jonathan Stickel)]

Cc Me!

[EJFielding (Eric Fielding)]

I am getting a related error when trying to build py27-scipy (py27-scipy-0.12.0_0+atlas+gcc45.darwin_11.x86_64.tbz2), but only on one of my machines. This seems to be the relevant line in the main.log:

:info:build ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so, 2): Symbol not found: _omp_get_num_threads

By the way, the build of atlas when I ran port upgrade outdated yesterday took like an hour to complete on my Mac Pro and two hours on my MacBook.

port installed atlas
The following ports are currently installed:
  atlas @3.10.0_1+gcc45
  atlas @3.10.1_1+gcc45
  atlas @3.10.1_2+gcc45
  atlas @3.10.1_3+gcc47 (active)

[EJFielding (Eric Fielding)]

Cc Me!

[michaelld (Michael Dickens)]

I think the latest atlas should work for most folks so long as you're not building atlas +universal. I think the following will work:

sudo port -f uninstall atlas pyXY-numpy
sudo port selfupdate
sudo port install atlas +variants
sudo port install pyXY-numpy +atlas +variants

but replace "XY" by the correct python version, and "+variants" by your chosen variants (e.g., "+gcc47"). I'm pretty sure you need to start by reinstalling atlas, then numpy, in that order. And, that you need to uninstall them first. Anyway, this is worth a try, since in my testing the latest atlas builds natively correctly, linking with -lgomp so that the _omp_* symbols will be defined in the resulting atlas libraries.

[gorticus (Jason Mitchell)]

Replying to michaelld@…:

I see this issue too (I cannot actually compile the latest atlas, but the issue is also with the prior version):

nm -a `port contents atlas | grep libatlas` | grep omp_get_num_threads

returns "U _omp_get_num_threads" meaning that that symbol is undefined in the library. Hence, it seems like either libatlas.a needs to statically link with ${prefix}/lib/gccXY/libgomp.a, or any project using this library needs to link with ${prefix}/lib/gccXY/libgomp.dylib or .a. Basically: this seems to be an atlas issue, not a numpy issue. Or, maybe I'm missing something?

I see the same result/issue, even following your suggestion in comment:28 below. The only way I've been able to get py27-numpy and py27-scipy, and opencv+python27 is to drop atlas. I haven't tried the gcc45 trick, or the suggestion in ticket:38724#comment:24.

[gorticus (Jason Mitchell)]

Replying to jason-macports@…:

Replying to michaelld@…:

I see this issue too (I cannot actually compile the latest atlas, but the issue is also with the prior version):

nm -a `port contents atlas | grep libatlas` | grep omp_get_num_threads

returns "U _omp_get_num_threads" meaning that that symbol is undefined in the library. Hence, it seems like either libatlas.a needs to statically link with ${prefix}/lib/gccXY/libgomp.a, or any project using this library needs to link with ${prefix}/lib/gccXY/libgomp.dylib or .a. Basically: this seems to be an atlas issue, not a numpy issue. Or, maybe I'm missing something?

I see the same result/issue, even following your suggestion in comment:28 below. The only way I've been able to get py27-numpy and py27-scipy, and opencv+python27 is to drop atlas. I haven't tried the gcc45 trick, or the suggestion in ticket:38724#comment:24.

Nope. The suggestion in ticket:38724#comment:24 didn't work. I'm stuck with using non-atlas versions until this is addressed.

[shapovalow@…]

Cc Me!

[mf2k (Frank Schima)]

I am still seeing this problem on some computers. It seems to work if atlas is built with mpclang33 but not with gcc47.

[jjstickel (Jonathan Stickel)]

Replying to macsforever2000@…:

I am still seeing this problem on some computers. It seems to work if atlas is built with mpclang33 but not with gcc47.

I can confirm:

  atlas @3.10.1_3+mpclang33 (active)
  py27-numpy @1.7.1_0+atlas+gcc47 (active)
  py27-scipy @0.12.0_1+atlas+gcc47 (active)

seems to be working for me. Atlas took hours to build, though. I see that there is a revision 4 for atlas now, but I am not inclined to rebuild right away.

Now I am having trouble building DSDP, where I am getting errors when linking to lapack libraries. I'll see if I can sort that out, or I'll post a separate ticket.

[mf2k (Frank Schima)]

After r105494, atlas built with mpclang33 does again fix the problem.

$ port installed atlas py27-numpy clang-3.3 llvm-3.3
The following ports are currently installed:
  atlas @3.10.1_4+mpclang33 (active)
  clang-3.3 @3.3-r180025_0+analyzer+assertions+python27 (active)
  llvm-3.3 @3.3-r180025_0+assertions (active)
  py27-numpy @1.7.1_0+atlas+gcc47 (active)

If atlas is built with the gcc47 variant, then I see this problem.

[michelle.lynn.gill@…]

Cc Me!

[maciej.bilas@…]

Cc Me!

[beany_kelly@…]

I just went through and tried reinstalling the following with gcc46 [gcc46 @4.6.4_0] (gcc45 doesn't seem to be an option for atlas any more) and python26 [python26 @2.6.8_0]:

atlas @3.10.1_5+gcc46

py26-numpy @1.7.1_0+atlas+gcc46

With all that in place, I'm still seeing the problem described at the start of this ticket:

Traceback (most recent call last):
  File "../../../python/fitStrainRate_IRS.py", line 1, in <module>
    import numpy as np
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/__init__.py", line 137, in <module>
    import add_newdocs
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/add_newdocs.py", line 9, in <module>
    from numpy.lib import add_newdoc
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/__init__.py", line 13, in <module>
    from polynomial import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/polynomial.py", line 17, in <module>
    from numpy.linalg import eigvals, lstsq, inv
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/__init__.py", line 48, in <module>
    from linalg import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/linalg.py", line 23, in <module>
    from numpy.linalg import lapack_lite
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so, 2): Symbol not found: _omp_get_num_threads
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so

So it seems that moving everything back from gcc47 to gcc46 doesn't fix the problem, at least for me.

[mf2k (Frank Schima)]

Did you rebuild py26-numpy?

[Veence (Vincent)]

Before you rebuild with clang33, can you do a

otool -L /opt/local/lib/libtatlas.dylib

And the same for libsatlas.dylib?

Thanks!

[beany_kelly@…]

Replying to vince@…:

Before you rebuild with clang33, can you do a

otool -L /opt/local/lib/libtatlas.dylib

And the same for libsatlas.dylib?

Thanks!

Sure. Here's the tatlas result:

/opt/local/lib/libtatlas.dylib:
	/opt/local/lib/libtatlas.dylib (compatibility version 3.10.1, current version 3.10.1)
	/opt/local/lib/gcc46/libgomp.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/gcc46/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/opt/local/lib/gcc46/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

... and here's satlas:

/opt/local/lib/libsatlas.dylib:
	/opt/local/lib/libsatlas.dylib (compatibility version 3.10.1, current version 3.10.1)
	/opt/local/lib/gcc46/libgomp.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/gcc46/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/opt/local/lib/gcc46/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

[beany_kelly@…]

Cc Me!

[Veence (Vincent)]

Strange but reassuring: the GNU OpenMP library is correctly referenced by lib[ts]atlas. Can you check that libgomp library you get in the result of otool exists (in /opt/local/gcc46)?

If yes, then it can you do the same otool with the lapack_lite.so library whence the error seems to stem? I have an inkling of what going on there, but I need to confirm it. Thanks again!

[beany_kelly@…]

Replying to vince@…:

Sorry for the delay in replying. I'd started doing the "+mpclang33" version of the atlas install, but it was taking *ages* (MUCH longer than the gcc46 version, which only takes around 30 minutes; perhaps the gcc version doesn't actually optimise?) Anyway, I abandoned that for the moment, and restored the gcc46 setup from my Comment 37 above.

Strange but reassuring: the GNU OpenMP library is correctly referenced by lib[ts]atlas. Can you check that libgomp library you get in the result of otool exists (in /opt/local/gcc46)?

Yes, I've verified that /opt/local/lib/gcc46/libgomp.1.dylib exists.

If yes, then it can you do the same otool with the lapack_lite.so library whence the error seems to stem? I have an inkling of what going on there, but I need to confirm it. Thanks again!

Here's the result of running otool -L on /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so :

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so:
	/opt/local/lib/gcc46/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
	/opt/local/lib/gcc46/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/gcc46/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

[jjstickel (Jonathan Stickel)]

Replying to beany_kelly@…:

Replying to vince@…:

Sorry for the delay in replying. I'd started doing the "+mpclang33" version of the atlas install, but it was taking *ages* (MUCH longer than the gcc46 version, which only takes around 30 minutes; perhaps the gcc version doesn't actually optimise?)

With mpclang33 it took 6 hours on my 3-4 year old Macbook Pro. I don't remember it taking more than an hour with gcc. This is a significant drawback for clang builds and will result in a lot of complaints from users if it becomes the default. I also don't know how the atlas computational efficiencies compare between gcc and clang builds.

[mf2k (Frank Schima)]

And yet it's completely useless if it doesn't work with numpy and others.

[Veence (Vincent)]

I think the problem is caused by numpy linking against the .a version of Atlas libs. These .a files are static archives that are supposed to be self-contained, so the linkers picks routines up here and there out of the archive and bundles them into the file it is building without minding about dependencies, that must be specified in addition. But, in that case, Atlas introduces a further dependency, that does not seem to be taken into account by the Makefile, specifically to the famous libgomp (OpenMP threading) in the GCC standard lib. So, the fix would be either to specify an extra dependency to ${prefix}/bin/gccXX/libgomp.dylib, which might be impractical because XX should be inferred and is found different places in universal builds, or to alter the dependency to link against Atlas dylibs, which would pull automatically the correct libgomp dependency in.

[Veence (Vincent)]

BTW, Atlas builds quickly with gccXX because it has, for GCC only, a set of precomputed figures optimizing the various parameters of the different kernels. In the case of Clang, no such set is available, so Atlas goes through the whole process of testing each combination of parameters to find the best one. Takes several hours (usually ca. 4 to 6) But now that Clang correctly compiles Atlas, it is probable that Clint Whaley, the senior developer, will include precomputed figures for Clang in a future revision.

[Veence (Vincent)]

I have written a patch that replaces the link with libatlas.a by a link with lib[ts]atlas.dylib, which is fine. *But* it appears OpenMP does not work correctly (numpy fails on an Atlas OpenMP call). I have therefore disabled OpenMP use in Atlas build. I am rebuilding Atlas, and if numpy works correctly with both patches, I’ll commit them.

[Veence (Vincent)]

Should (at last) be fixed in r105864. Please rebuild atlas and then numpy. Thanks.

[beany_kelly@…]

Replying to vince@…:

Should (at last) be fixed in r105864. Please rebuild atlas and then numpy. Thanks.

Hi Vince. Great news! Should we end-users be able to get the new atlas & numpy right now, or are there intermediate steps? Because nothing happens when I do "port upgrade outdated" ...

[Veence (Vincent)]

I did not bump the revision of either port because the bug impacts only people compiling Atlas with gcc (not with clang, because clang does not support OpenMP yet). A revbump would have caused everyone to recompile.

Just wait for a few minutes, do a port selfupdate (verify that you have r105864) and then rebuild both ports (force a desinstall then reinstall).

[beany_kelly@…]

Updated, reinstalled atlas +gcc46, numpy , etc. ... and it works!

I haven't tried with gcc47; I'll probably stick with gcc46 for the moment.

Thanks again!

[Veence (Vincent)]

I have tried with gcc47 and numpy passes all tests, so I assume it works correctly. That’s good news, but at the same it isn’t, since according to Clint Whaley, using pthreads for threading (what we have reverted to with this last patch) instead of OpenMP means a performance penalty. But, as always, a working version of Atlas, even slightly crippled, is better than no Atlas at all. Have fun

[mf2k (Frank Schima)]

Yes, works for me too!

$ port installed atlas py27-numpy
The following ports are currently installed:
  atlas @3.10.1_5+gcc47 (active)
  py27-numpy @1.7.1_0+atlas+gcc47 (active)

$ ipython
Python 2.7.3 (default, Nov 17 2012, 19:54:34) 
Type "copyright", "credits" or "license" for more information.

IPython 0.13.2 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import numpy

In [2]: 

[mf2k (Frank Schima)]

Cc reporter of duplicate #39141.

[mf2k (Frank Schima)]

Cc reporter of duplicate #39271.

[bgschaid@…]

Cc Me!