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?).
regards,
Kenneth
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
