libgfortran.so.1

[ktavabi]

Sometime ago I noticed that my installation of MNE-Nightly-Linux-x86_64 was missing libgfortran.so.1 in the $MNE_ROOT/lib directory. I searched the MNE Analysis archives and found an older post by @Eric89GXL that provided a url for downloading the file. Initially I tried the 64bit version of this file that for some reason was incompatible, but I didn't bother trouble shooting it because the 32 bit version worked on my 64 bit system! Next, I started receiving some thorny python errors related to libgfortran.so.1. Apparently, in the ANACONDA environment @dengemann there is already a version of this library file that is used by various packages, and issues arise when mne_setup_sh sets the environment variable LD_LIBRARY_PATH to $MNE_ROOT/lib. After considerable effort I resorted to just creating aliases that either (1) set up the MNE environment OR (2) clear LD_LIBRARY_PATH and allow for ANACONDA python environment to run. In hindsight this is not a optimal fix, because now I have to figure out how to e.g., call mne_create_sourcespace in a shell script from python --there is a conflict since both the python environment and MNE specifically require LD_LIBRARY_PATH and/or libgfortran.so.1 in their "special" way. Has anyone dealt with this? Some insight would be much appreciated.

[dengemann]

Hi Kam,

'unfortunately' I did not have such a problem with the standard Linux Python stack / on OS X using Canopy64. For the latter I simply put the library file into the MNE root location you mentioned while I think on OS X everything worked out of the box. My less patient take on this would be to proceed using two shell sessions, one for Python, one for MNE. In the latter l would run shell scripts as proposed here: https://github.com/mne-tools/mne-scripts/tree/master/sample-data, in the former only Pyhton.

Btw. you can now also create source spaces from within Python: https://github.com/mne-tools/mne-scripts/tree/master/sample-data

Anyways, thanks for reminding me that I wanted to take closer look at Anaconda.

[agramfort]

thanks Kam for the bug report. THis libgfortran.so.1 issue is recurrent and
I am not sure how to fix it. You seem to indicate that even if we ship it
with the binaries it will break things like anaconda... the joy of
releasing C/C++ code :)

[dengemann]

@kambysese what's the status here? Can we close?

[agramfort]

no. It's still a recurrent problem. The mne nightly build needs to be fixed
:(

[ktavabi]

Hi @dengemann in all honesty I have not revisited this issue on my end since working around it by using different aliases for different environments.

[dengemann]

@kambysese some news on this.

while it has been annoying me for some time that the DYLD_LIBRARY_PATH in /Applications/MNE-2.7.4-3378-MacOSX-x86_64/bin/mne_setup_sh I found some time to look into it.
Note. setting this path can be evil on Mac OS X especially for recent versions and when using homebrew (https://github.com/mxcl/homebrew) as a Unix package manager. E.g. brew doctor would yell at you not to set this path ... Moreover, the gitk GUI will not work as long as the MNE sets the DYLD_LIBRARY_PATH (but it works fine if I start a plain vanilla shell without initializing MNE or just commenting replacing line 77 with echo ''.
The good news is that mne_analysis seems happy with libquicktime as installed via brew, also gfortran can be installed via brew.
I'm now enjoying a setup in which brew contributes the libraries MNE depends on and the Python part is performed by Anaconda (1.7.0). Seems to work flawlessly and in concert.
We might consider updating the mne_setup_sh script accordingly.

cc @agramfort @Eric89GXL

[agramfort]

On Sun, Oct 20, 2013 at 12:44 PM, Denis A. Engemann <
notifications@github.com> wrote:

We might consider updating the mne_setup_sh script accordingly.

how? detect the installation of brew?

[dengemann]

how? detect the installation of brew?

yes, for example. We could try to detect brew and prompt users to use it to install the dependencies. If on Mac + no brew, default to ship libraries + add warning.

[dengemann]

@agramfort we could do this:

https://gist.github.com/dengemann/7086909

elif [ "x$OS" == "xDarwin" ] ; then
    set_dyld_path=0
    if command_exists brew ; then
        brew_loc=$(command -v brew)
        echo Brew install detected at: ${brew_loc}
        if ! brew list | grep libquicktime &> /dev/null; then
            echo '... please consider installing libquicktime';
            set_dyld_path=1
        fi
        if ! brew list | grep gfortran &> /dev/null; then
            echo '... please consider installing gfortran';
            set_dyld_path=1
        fi
    else
    set_dyld_path=1 
    fi  
    if [[ set_dyld_path == 1 ]]; then
        echo falling back to shipped libraries
        if [ ! "$DYLD_LIBRARY_PATH" ] ; then
            DYLD_LIBRARY_PATH=$MNE_LIB_PATH
        else
        DYLD_LIBRARY_PATH="$MNE_LIB_PATH":"$DYLD_LIBRARY_PATH"
        fi
        export DYLD_LIBRARY_PATH
        echo "${MNE_LIB_PATH} added to DYLD_LIBRARY_PATH"
    else
        echo using librarries from brew
    fi

fi

[ktavabi]

Thanks @dengemann for the heads up. I gather this fix doesn't apply to Linux distributions?

[dengemann]

Hey @kambysese right, you are on Linux, I forgot. You should try to copy the solution strategy, problems should be related / similar. It will probably take another 6 weeks until I take a look at Anaconda on Linux ...
But it would be great to tackle this in most generic fashion.

[dengemann]

@kambysese I'm actually quite sure the problem can be tackled using the same kind of approach. Get rid of library paths in you mne setup script and supply the libraries needed yourself. Carefully look at .bashrc / .cshrc lines that modify the PATH. Anaconda should be e.g. first / among the first entries.
Another cruel hack: some R packages ship / depend on the fortran library. I remember once having fixed this by installing a bunch of R packages.

[ktavabi]

@dengemann I will give it a try and let you guys know what happens.

[dengemann]

@kambysese could you roughly list your system specs. Maybe I'll find some time soonish and we can explore together.

[ktavabi]

Thank you @dengemann. Here is some info you asked for:

Distributor ID: LinuxMint
Description: Linux Mint 13 Maya
Release: 13
Codename: maya
Kernel: Linux version 3.2.0-23-generic (buildd@crested) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) )
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 24
Thread(s) per core: 2
CPU MHz: 1596.000
Virtualization: VT-x

Environments:
freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
MNE-2.7.4-3413-Linux-x86_64
conda version : 1.9.1 in ~/anaconda/lib/python2.7/site-packages/conda (with most if not all python packages at current stable release version e.g., numpy, scipy, matplotlib, etc.) and mnepy version 0.7.git

[MadsJensen]

I know it's a late reply but it still might be useful. I'm on a Linux Mint 16 and has had the same problem on different machines (also opensuse). I fixed it by installing the libgfortran available (for me libgfortran.so.3) and made a symbolic link to it.

/usr/lib/x86_64-linux-gnu/libgfortran.so.1 -> /usr/lib/x86_64-linux-gnu/libgfortran.so.3

i.e. the command is (from memory):

ln -s  /usr/lib/x86_64-linux-gnu/libgfortran.so.3  /usr/lib/x86_64-linux-gnu/libgfortran.so.1

[agramfort]

yes I know... we need to fix this :-/ it's due to an update to the nightly
build system ....

[larsoner]

It looks like people have found workable solutions for this, so I'm going to close.

[kingjr]

Encountered the problem again on a recent ubuntu 14.04 + conda install.

It used to work. Not sure what happened in between...

@MadsJensen 's trick fixed it.

[ktavabi]

@kingjr this issue never went away. I've been linking to libgfortran3.so that comes with anaconda.

[kingjr]

We should add something in the FAQ then if we can't fix it.