On Wed, Sep 5, 2018 at 5:38 PM David Grote <dpgrote@lbl.gov> wrote:

Hi - I have recently come across this problem. On my mac, I build a Fortran code, producing a shared object, that I import into Python along with numpy. This had been working fine until recently when I started seeing sag faults deep inside the Fortran code, usually in Fortran print statements. I tracked this down to a gfortran version issue.

I use the brew installation of Python and gcc (using the most recent version, 8.2.0). gcc of course installs a version of libgfortran.dylib. Doing a lsof of a running Python, I see that it finds that copy of libgfortran, and also a copy that was downloaded with numpy (/usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib). Looking at numpy's copy of libgfortran, I see that it is version 4.9.0, much older. Since my code is importing numpy first, the OS seems be using numpy's version of libgfortran to link when importing my code. I know from other experience that older versions of libgfortran are not compatible with code compiled using a new version of gfortran and so therefore segfaults happen.

If I download the numpy source and do python setup.py install, I don't have this problem.

After this long description, my question is why is such an old version of gcc used to build the distribution of numpy that gets installed from pypi? gcc version 4.9.0 is from 2014. Can a newer version be used?

The library came in with the use of OpenBLAS, I don't think there is a fundamental reason that a newer version of gfortran couldn't be used, but I have little experience with the Mac. Note that we have also given up on 32 bit Python on Mac for library related reasons. Matthew Brett would be the guy to discuss this with.

ChuckÂ