py27-scipy @0.13.3_0: import scipy.linalg fails with Symbol not found: _acc_cdotc_sub__

[andregirard]

System is 10.7.5. No pending software updates. Fresh selfupdate and uggrade outdated. No errors. Then

Andre-Girards-MacBook-Pro:Power_heur andre$ python
Python 2.7.6 (default, Nov 12 2013, 13:12:10) 
[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 scipy.linalg
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/scipy/linalg/__init__.py", line 157, in <module>
    from .misc import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/misc.py", line 5, in <module>
    from . import blas
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/blas.py", line 131, in <module>
    from scipy.linalg import _fblas
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/_fblas.so, 2): Symbol not found: _acc_cdotc_sub__
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/_fblas.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/_fblas.so

[andregirard]

Same problem after upgrading to Xcode 4.6.3

[larryv (Lawrence Velázquez)]

I don’t have any problem with this on Mavericks.

% port installed py27-scipy
The following ports are currently installed:
  py27-scipy @0.13.3_0+gcc48+universal (active)
% /opt/local/bin/python2.7
Python 2.7.6 (default, Feb  3 2014, 23:45:08) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy.linalg
>>> exit()
%

[vlsd (Vlad)]

Exact same issue on 10.9.2, so it *does* happen on some Mavericks machines. I am, however running py27-scipy @0.13.3_0+gcc47. After switching to gcc48 variant I no longer get this error.

[larryv (Lawrence Velázquez)]

Cc Me!

[titusjan@…]

I had the same issue (on OS-X 10.6 and using py27-scipy @0.13.3_0+gcc45) but switching to the gcc48 variant solved the issue for me as well. Thanks vloodo.

[andregirard]

Replying to titusjan@…:

I had the same issue (on OS-X 10.6 and using py27-scipy @0.13.3_0+gcc45) but switching to the gcc48 variant solved the issue for me as well. Thanks vloodo.

This solves the problem on 10.7.5 also. Thanks

[axel.roebel@…]

I have just created a new install on OSX 10.9 using the default variant (gcc48)

#:598> port installed py27-scipy
The following ports are currently installed:
  py27-scipy @0.13.3_0+gcc48 (active)

and I have the same problem

dlopen(/u/formes/share/packages/macports/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/linalg/_fblas.so, 2): Symbol not found: _acc_cdotc_sub__

any ideas?

[neverpanic (Clemens Lang)]

I can reproduce this issue. _fblas.so has two similarly named symbols _acc_cdotc_sub_ (which is present and exported) and _acc_cdotc_sub__, which is unresolved and causes the issue.

I'm not sure why these symbols are missing and where they are supposed to come from, though -- my knowledge of Fortran is somewhat nonexistent.

[neverpanic (Clemens Lang)]

I think this might be related to whether Atlas is installed or not (that's quite the long shot, though). It would be helpful to see the the logs of a build that produced a working binary and the log of one that doesn't.

[neverpanic (Clemens Lang)]

Installing the atlas port and rebuilding py27-scipy fixes the problem for me. I guess py27-scipy should depend on Atlas instead of using Accelerate.framework?

[seanfarley (Sean Farley)]

Replying to cal@…:

Installing the atlas port and rebuilding py27-scipy fixes the problem for me. I guess py27-scipy should depend on Atlas instead of using Accelerate.framework?

Let's try to fix the fortran linking issue instead of requiring atlas. Cal, are you building scipy from scratch or using a binary from the buildbots?

[neverpanic (Clemens Lang)]

I'm not sure now that you mention it. The binary from the buildbot works for me even with atlas deactivated. Let me re-try to reproduce with a source install without atlas.

[neverpanic (Clemens Lang)]

Source build without atlas active produces a broken installation. I'll attach the log.

[seanfarley (Sean Farley)]

Replying to cal@…:

Source build without atlas active produces a broken installation. I'll attach the log.

More likely than not, it's picking up atlas when it shouldn't. The underscores in fortran linking are usually determined in the configure step (this applies to most packages, in general, by the way).

[neverpanic (Clemens Lang)]

Replying to sean@…:

More likely than not, it's picking up atlas when it shouldn't. The underscores in fortran linking are usually determined in the configure step (this applies to most packages, in general, by the way).

Definitely not the case. Atlas was deactivated and I was building with trace mode enabled, which would have hidden any Atlas files anyway. The log will take a few minutes, though, because I used install and forgot to provide -k.

[seanfarley (Sean Farley)]

Replying to cal@…:

Replying to sean@…:

More likely than not, it's picking up atlas when it shouldn't. The underscores in fortran linking are usually determined in the configure step (this applies to most packages, in general, by the way).

Definitely not the case. Atlas was deactivated and I was building with trace mode enabled, which would have hidden any Atlas files anyway. The log will take a few minutes, though, because I used install and forgot to provide -k.

Yeah, I totally replied to your previous comment in my email browser and didn't even read what was on this page first before posting >_< I'll have to look into later today after I update my ports.

[neverpanic (Clemens Lang)]

main.log of the broken build (without atlas)

[neverpanic (Clemens Lang)]

main.log of the working build (with atlas)

[sarahaskendrew@…]

Atlas or no atlas makes no difference for me. I have two computers running the same OS (OSX 10.8.5) and same versions of python (2.7.6) and scipy (0.13.3+gcc48); I get the error on importing scipy.linalg for one but not the other. Neither had atlas installed. I installed atlas on the one with the error and reinstalled py27-scipy and the error is persisting. Suggestions?

[neverpanic (Clemens Lang)]

Replying to sarahaskendrew@…:

Atlas or no atlas makes no difference for me. I have two computers running the same OS (OSX 10.8.5) and same versions of python (2.7.6) and scipy (0.13.3+gcc48); I get the error on importing scipy.linalg for one but not the other. Neither had atlas installed. I installed atlas on the one with the error and reinstalled py27-scipy and the error is persisting. Suggestions?

If neither of your boxes had Atlas installed that further complicates things and means there might be another reason for this after all. I think the binary (for darwin13) also worked fine for me but my own build from source did not (which is completely unexpected for me).

However, I still think installing atlas and rebuilding py27-scipy might help, but you probably only got the binary from the buildbot when you did that. Can you try again using

sudo port -nfs upgrade py27-scipy

• -f will force the upgrade even though py27-scipy isn't outdated
• -n will only force the upgrade for py27-scipy, but not its dependencies
• -s will force a build from source.

[seanfarley (Sean Farley)]

Replying to sarahaskendrew@…:

Atlas or no atlas makes no difference for me. I have two computers running the same OS (OSX 10.8.5) and same versions of python (2.7.6) and scipy (0.13.3+gcc48); I get the error on importing scipy.linalg for one but not the other. Neither had atlas installed. I installed atlas on the one with the error and reinstalled py27-scipy and the error is persisting. Suggestions?

It might be picking up the wrong gfortran from MacPorts. Can you send the output of port select --list gcc?

[petrrr]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #43135.

[petrrr]

Looking through this ticket, I have the impression ticket #43083 might be related. The build problem is different. However, non functioning binary package is probably related.

I got quite some length test output by nosetests from my colleague. The starting part is probably the most interesting.

irene$ nosetests-2.7 scipy 2>&1 > error_nosetests_scipy_irene
RuntimeError: module compiled against API version 9 but this version of numpy is 6
RuntimeError: module compiled against API version 9 but this version of numpy is 6
RuntimeError: module compiled against API version 9 but this version of numpy is 6
[... repeated several times ...]
E...............EEEEEE......EEE...............SSSSSSEEEEEEEE...................................................................................................................................................................................E...........................................E.E....................................................................................................................................................................................................................................

plenty of import errors

----------------------------------------------------------------------
Ran 514 tests in 253.184s

FAILED (SKIP=6, errors=21)

[petrrr]

Replying to cal@…:

Installing the atlas port and rebuilding py27-scipy fixes the problem for me. I guess py27-scipy should depend on Atlas instead of using Accelerate.framework?

This sounds more like a opportunistic linking issue. I believe I observed this before (when activation py34-scipy subport) but was never sure and have not done further tests yet.

[petrrr]

Replying to cal@…:

I can reproduce this issue. _fblas.so has two similarly named symbols _acc_cdotc_sub_ (which is present and exported) and _acc_cdotc_sub__, which is unresolved and causes the issue.

I'm not sure why these symbols are missing and where they are supposed to come from, though -- my knowledge of Fortran is somewhat nonexistent.

This looks like wrapping. But when looking in my "working" version the _acc_cdotc_sub_ symbol is present as target, no _acc_cdotc_sub__ symbol though ...

[petrrr]

Note that I had no problems before (not sure but probably installed the binary package), but trying to reproduce problems of colleges. So, I too some time and did various test on my machine:

Retina, 15-inch, Early 2013
2.7 GHz Intel Core i7
OS X 10.8.5 (12F45)
Xcode 4.6.2
Build version 4H1003
MacPorts 2.2.1

Summary:

1. With the binary packages all seems to works just fine: all tests pass or kownfail;
2. Build from source (atlas was active): compiles well, but test bombs. It looks like the build is using atlas library even if variant +atlas is not requested;
3. Build from source, after atlas is deactivated: compiles well, but test show the same behavior as reported here, symbol _acc_cdotc_sub__ unresolved.
4. Build from source, now atlas activated again and build with +atlas variant: testing shows same behavior as 2.

So my preliminary conclusions:

(1) The binary packages still works for me (and probably for most others, but not all). However, source builds are broken and have the reported problem (not sure if this is generally true, or only in some cases). Therefore, I would assume that the "solution" to use +gcc48 (default variant) instead of +gcc47 or any other compiler, is not really related to the compiler choice. Instead, this caused the binary package to be fetched instead of building from source (which is broken).

(2) There are two unrelated issues with ATLAS:

• If atlas is activated, scipy always builds against atlas, ignoring whether +atlas variant is requested or not; However, if it is not requested the dependency is not registered correctly;
• scipy build against atlas (w and w/o the +atlas variant) is broken at least on some platforms;

I propose to stick with problem (1) here, and I will file a independent ticket for problems (2).

Now back to problem (1):

We would need to understand why py-scipy builds correctly on the buildbot, and fails on other machines. Is it on all or only on some? What is the difference what causes this.

The build is from 04-Feb-2014. r117983 only adds py34 subport and this was build 25-Mar-2014; Would it still build correctly on the bot? Or might this be a regression? r117037 could be relevant here (no revision bump) or some change in base? Are there any relevant ones?

Any possibility to test this without overwriting the current binary package?

[petrrr]

I have a last piece of information for you, which I think is useful here. I just looked at the py34-scipy binary package, which was created by the buildbot later then the other packages (see above).

Below the relevant snippet from the test. For the binary package of py34 subport, we have the same problem as for the source builds, which were created by individuals. So this is very likely a regression introduced after r116719, 2 Feb 2014.

ERROR: Failure: ImportError (dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so, 2): Symbol not found: _acc_cdotc_sub__
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/failure.py", line 39, in runTest
    raise self.exc_val.with_traceback(self.tb)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/loader.py", line 411, in loadTestsFromName
    addr.filename, addr.module)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 245, in load_module
    return load_package(name, filename)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 217, in load_package
    return methods.load()
  File "<frozen importlib._bootstrap>", line 1220, in load
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1448, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/interpolate/__init__.py", line 162, in <module>
    from .rbf import Rbf
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/interpolate/rbf.py", line 51, in <module>
    from scipy import linalg
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/__init__.py", line 157, in <module>
    from .misc import *
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/misc.py", line 5, in <module>
    from . import blas
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/blas.py", line 131, in <module>
    from scipy.linalg import _fblas
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so, 2): Symbol not found: _acc_cdotc_sub__
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/scipy/linalg/_fblas.so

======================================================================

[sarahaskendrew@…]

Replying to sean@…:

Replying to sarahaskendrew@…:

Atlas or no atlas makes no difference for me. I have two computers running the same OS (OSX 10.8.5) and same versions of python (2.7.6) and scipy (0.13.3+gcc48); I get the error on importing scipy.linalg for one but not the other. Neither had atlas installed. I installed atlas on the one with the error and reinstalled py27-scipy and the error is persisting. Suggestions?

It might be picking up the wrong gfortran from MacPorts. Can you send the output of port select --list gcc?

Sorry been away! Rebuilt py27-scipy as instructed; this made no difference.

Output re. gcc:

~ kendrew$ port select --list gcc Available versions for gcc:

llvm-gcc42 mp-gcc48 none (active)

[sarahaskendrew@…]

Cc Me!

[petrrr]

Replying to sarahaskendrew@…:

Replying to sean@…:

Replying to sarahaskendrew@…:

Atlas or no atlas makes no difference for me. I have two computers running the same OS (OSX 10.8.5) and same versions of python (2.7.6) and scipy (0.13.3+gcc48); I get the error on importing scipy.linalg for one but not the other. Neither had atlas installed. I installed atlas on the one with the error and reinstalled py27-scipy and the error is persisting. Suggestions?

It might be picking up the wrong gfortran from MacPorts. Can you send the output of port select --list gcc?

Sorry been away! Rebuilt py27-scipy as instructed; this made no difference.

Have you installed both from sources, both via binary package, mix? If you installed from sources, when did this happen?

I suspect currently source build is broken. If you do not see problems on one computer it (1) might have been installed from binary package (seems to be still working for 10.8.5) or (2) it was build before the change which broke the port.

I have no idea what broke the port though ...

[buchere@…]

Hi There, I am running
+ OSX 10.8.5 (mountain lion)
+ MacPorts 2.2.1
+ gcc 4.8.2
I have not had installed atlas

I recently upgraded to python 3.4 and was running in the error mentioned above. The following worked for me:

port uninstall py34-scipy
port select --set gcc mp-gcc48
hash gcc
port install atlas
port install -s py34-scipy

Thanks for all the ones who reported what they know. Elmar

[petrrr]

Replying to buchere@…:

Hi There, I am running
+ OSX 10.8.5 (mountain lion)
+ MacPorts 2.2.1
+ gcc 4.8.2
I have not had installed atlas

I recently upgraded to python 3.4 and was running in the error mentioned above. The following worked for me:

port uninstall py34-scipy
port select --set gcc mp-gcc48
hash gcc
port install atlas
port install -s py34-scipy

Have you run the tests? Does your installation finish a tests (even if they do not pass). I am asking because I get a Segmentation fault at some point, when testing an installation against altas. Thanks!

[sarahaskendrew@…]

Replying to buchere@…:

Hi There, I am running
+ OSX 10.8.5 (mountain lion)
+ MacPorts 2.2.1
+ gcc 4.8.2
I have not had installed atlas

I recently upgraded to python 3.4 and was running in the error mentioned above. The following worked for me:

port uninstall py34-scipy
port select --set gcc mp-gcc48
hash gcc
port install atlas
port install -s py34-scipy

Thanks for all the ones who reported what they know. Elmar

Thanks. Is it important in this step to uninstall and reinstall atlas? I already have atlas installed and tried it without this step, which didn't work (as installing atlas takes ages!). Also on my 2nd computer that doesn't have this issue I don't have atlas installed so it doesn't seem relevant to the problem.

[seanfarley (Sean Farley)]

Ok, I can reproduce this error. Hopefully, I'll be able to figure it out soon.

[seanfarley (Sean Farley)]

A few things:

• I observed opportunistic linking with ATLAS which will definitely need to be fixed
• The extra underscore is from:

​https://github.com/scipy/scipy/blob/master/scipy/_build_utils/src/wrap_g77_abi_c.c#L3

This is why I hate fortran. Unless you want to keep a mapping of which fortran compilers put underscores on different systems, you can't know beforehand what the name mangling will be. This explains why linking with ATLAS works because this file is only compiled when linking with Accelerate. Somehow numpy.distutils is providing -fno-second-underscore for the fixed-form compiler but not every fortran compiler. I should have a fix soon.

[petrrr]

Sean, thanks for looking into this.
For the ATLAS issues, should we open separate ticket(s)?

[seanfarley (Sean Farley)]

Replying to Peter.Danecek@…:

Sean, thanks for looking into this.
For the ATLAS issues, should we open separate ticket(s)?

Nah, don't worry about it. It's already fixed in my local repo. Just tackling some other tickets and testing before I push.

[petrrr]

Great! But note that I observe also a Segmentation Fault while testing py-scipy build against ATLAS (comment:22 item 2/4). Are you able to reproduce this, or is this an individual problem?

[seanfarley (Sean Farley)]

Replying to Peter.Danecek@…:

Great! But note that I observe also a Segmentation Fault while testing py-scipy build against ATLAS (comment:22 item 2/4). Are you able to reproduce this, or is this an individual problem?

I think my change inadvertently fixed this, too. I'm testing it out now.

[seanfarley (Sean Farley)]

Replying to sean@…:

Replying to Peter.Danecek@…:

Great! But note that I observe also a Segmentation Fault while testing py-scipy build against ATLAS (comment:22 item 2/4). Are you able to reproduce this, or is this an individual problem?

I think my change inadvertently fixed this, too. I'm testing it out now.

Nope, still segfaults. If you don't mind doing so, go ahead and open a new ticket for this and assign it to me.

[seanfarley (Sean Farley)]

Fixed in r118776. Thanks for the report! For the other issues, please open a new ticket.

[petrrr]

Thanks for the work on this issue! I redo the tests and compile the tickets with updated information.