3 different results from same pyimport command issued 3 times in a row

[eflister]

this is matlab 2015a, macports python 2.7, osx 10.10.3

>> pyimport sima            
Error using pymex
Python:RuntimeError -> Interface initialization failed (Not a datatype object)


Error in pyimport (line 6)
    imp = pymex('IMPORT', name);

>> pyimport sima
Error using pymex
Python:ImportError ->
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/special/_ufuncs.so, 2): Symbol not
found: __gfortran_stop_numeric_f08
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/special/_ufuncs.so
  Expected in: /Applications/MATLAB_R2015a.app/sys/os/maci64/libgfortran.3.dylib
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/special/_ufuncs.so


Error in pyimport (line 6)
    imp = pymex('IMPORT', name);

>> pyimport sima
Error using pymex
Python:ImportError -> cannot import name hough_ellipse

to show pymex is working:

>> pyimport numpy
>> numpy.asarray(rand(2,3,4))

ans = 

[[[ 0.81472369  0.27849822  0.95716695  0.79220733]
  [ 0.12698682  0.95750684  0.80028047  0.6557407 ]
  [ 0.63235925  0.15761308  0.42176128  0.84912931]]

 [[ 0.90579194  0.54688152  0.48537565  0.95949243]
  [ 0.91337586  0.96488854  0.14188634  0.03571168]
  [ 0.0975404   0.97059278  0.91573553  0.93399325]]]
>> ans.shape

ans = 

(2, 3, 4)

and

~/pymex$ make test
/Applications/MATLAB_R2015a.app/bin/matlab -nojvm -nodisplay \
    -r "pyimport nose; exit(unpy(~nose.run()));"

                                                         < M A T L A B (R) >
                                               Copyright 1984-2015 The MathWorks, Inc.
                                                R2015a (8.5.0.197613) 64-bit (maci64)
                                                          February 12, 2015


For online documentation, see http://www.mathworks.com/support
For product information, visit www.mathworks.com.


    Academic License

.....S..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 696 tests in 0.841s

OK (SKIP=1)

note the pymex py package is unusable, cuz it conflicts with matlab's new python bridge.

i am trying pymex cuz of this problem.

[kw]

I no longer own a copy of matlab, so this project is unfortunately unmaintained and I don't really have any way of testing anything, so everything here is guesswork and foggy memories of years past.

It would appear that matlab's copy of libgfortran.3.dylib lacks symbols that scipy is expecting to exist, most likely because scipy was compiled against a more recent libgfortran. A complicated workaround might be to figure out how to recompile scipy with libgfortran statically linked instead of dynamically linked. Alternatively, compile scipy against matlab's libraries - but it might not work outside of matlab if you do that.

A simple but potentially dangerous workaround is to take matlab's toys away. You can trying moving /Applications/MATLAB_R2015a.app/sys/os/maci64/libgfortran.3.dylib to somewhere else (don't delete it, you might need to put it back) and then start it up. With any luck it will link against whatever libgfortran scipy is expecting and just work. Matlab probably depends heavily on gfortran, though, so it may not start up if your system version is incompatible or matlab doesn't know where to find it. There may also be other dylibs in the maci64 directory that conflict with system libraries which could cause headaches. I recall having issues with libc++ in the past.

[eflister]

thanks for the response! i have been slowly realizing the same thing. but why the differing behavior for the first 3 identical attempts?

~$ DYLD_INSERT_LIBRARIES=/opt/local/lib/libgcc/libgfortran.3.dylib:/opt/local/lib/libtiff.5.dylib /Applications/MATLAB_R2015a.app/bin/matlab

allows sima/scipy/etc to load in matlab's own python bridge (didn't try in pymex, cuz that was the whole reason i needed pymex).

would just renaming your py module eliminate conflicts with matlab's new py bridge?

>> which py
/Applications/MATLAB_R2015a.app/toolbox/matlab/external/interfaces/python/py.m

[kw]

but why the differing behavior for the first 3 identical attempts?

Couldn't say, really. Importing python modules and dynamic linking of libraries is a complicated process with a lot of side effects. The state of a python extension module that tries to dynamic-link a library but fails to link all of the symbols probably isn't very well defined.

would just renaming your py module eliminate conflicts with matlab's new py bridge?

I don't think any pymex code directly uses py.m, so renaming it shouldn't be a problem. I'm not familiar with their new py bridge, though, so the +py package might also conflict somehow.