Hi Kenneth, Kenneth Hoste <[email protected]> writes:
> Hi Loris, > > I think the number at the end indicates the ABI (Application Binary Interface) > version. > > It's basically telling you that something was compiled against libgfortran > with > ABI version 4, and that it won't work if libgfortran with ABI version 5 would > be > used (since they're not binary compatible). > > This boils down to libgfortran.so.5 exporting a different set of symbols than > libgfortran.so.4 does, so you basically *must* recompile. > > In short: you can't use a numpy installation that was compiled with GCC 7.3 > when > GCC 8.3 is active, you have to recompile. > > I hope I'm not making any blatantly wrong statements here, but that's how I > understand it at least. ;) > I'm sure others will correct me if do (Markus?). This explanation seems right and corresponds to what a colleague of mine told me when I explained the issue. However, it seemed unlikely that EasyBuild would get me into this kind of trouble and it turns out that the real problem was in fact that I had omitted 'numpy' or rather 'SciPy-bundle' as a dependency in my EC, and so, when the program was run, a system version of numpy was being picked up which was obviously compiled with an older GCC. Adding 'SciPy-bundle' has solved that problem and allowed me to progress to the next one :-/ Thanks for the help, Loris > On 18/08/2020 14:51, Loris Bennett wrote: >> Hi, >> >> I have written an EC to install some Python codes as a tarball and >> successfully installed it. However, when the user tries to use it, he >> gets the following error: >> >> Importing the numpy c-extensions failed. >> ... >> Original error was: libgfortran.so.4: cannot open shared object file: No >> such file or directory >> >> I used the foss-2019b toolchain, which uses GGC 8.3.0, which has the >> following: >> >> $ ll libgfortran.so* >> lrwxrwxrwx 1 build staff 20 Sep 30 2019 libgfortran.so -> >> libgfortran.so.5.0.0 >> lrwxrwxrwx 1 build staff 20 Sep 30 2019 libgfortran.so.5 -> >> libgfortran.so.5.0.0 >> -rwxr-xr-x 1 build staff 10799408 Sep 30 2019 libgfortran.so.5.0.0 >> >> Version 4 of the library is available from GCC 7.3.0: >> >> $ ll libgfortran.so* >> lrwxrwxrwx 1 build staff 20 Jan 17 2019 libgfortran.so -> >> libgfortran.so.4.0.0 >> lrwxrwxrwx 1 build staff 20 Jan 17 2019 libgfortran.so.4 -> >> libgfortran.so.4.0.0 >> -rwxr-xr-x 1 build staff 7291944 Jan 17 2019 libgfortran.so.4.0.0 >> >> I can obviously rebuild the software with the appropriate toolchain, but >> I'd like to know what's going on. >> >> Why does numpy care about the version of libgfortran? Isn't the >> function of the link 'libgfortran.so' precisely to avoid this kind of >> breakage? >> >> Cheers, >> >> Loris >>
