
On Wed, Sep 5, 2018 at 4:37 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.
Normally on MacOS, it's fine to have multiple versions of the same library used at the same time, because the linker looks up symbols using a (source library, symbol name) pair. (This is called the "two-level namespace".) So it's strange that these two libgfortrans would interfere with each other. Does gfortran not use the two-level namespace when linking fortran code? -n -- Nathaniel J. Smith -- https://vorpus.org