libgfortran not linked properly

[jyoung]

I'm trying to use a binary application (DiskFit) that's trying to access libgfortran. I'm getting the error:

Code: Select all

DiskFit: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory

But, I have gcc installed with the fortran flag enabled, and libgfortran exists at this location:

Code: Select all

/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5

Although, the version is not the same. Any ideas?

I've also looked into compiling this application from source myself, but that doesn't look realistic at the moment.

[alamahant]

Hi
What is the package name for diskfit?
I cant find it.
How did you install it?

[GDH-gentoo]

I'm trying to use a binary application (DiskFit) that's trying to access libgfortran. I'm getting the error:

Code: Select all

DiskFit: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory

But, I have gcc installed with the fortran flag enabled, and libgfortran exists at this location:

Code: Select all

/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5

Although, the version is not the same.

As far as I can tell, libgfortran.so.3 was the libgfortran from the GCC 6 series. You have GCC 10.2.0, so of course DiskFit does not find it. That must be an old binary.

[jyoung]

It is an old binary. I'm an astronomer, and this is software that another astronomer developed, which is why it isn't in a package.

GDH-gentoo, that backs up an experiment I did on my end. I also have a debian box that's running gcc 6, and the binary works without issue there. gcc-6.5.0-r3 is still in portage, so maybe emerging that version will pull in the library.

[GDH-gentoo]

gcc-6.5.0-r3 is still in portage, so maybe emerging that version will pull in the library.

If you are going to install it, you will probably have to use eselect gcc set to temporarily switch to 6.5.0 before running DiskFit, and then back to 10.2.0 (or whatever is current as time passes) for everything else.

[jyoung]

Hi, that would be really unfortunate, if I had to eselect back and forth. I realize that this is a legacy application, but it would be great if there was an easier way.

However, I just tried it, and DiskFit still runs even if I've eselected for the newer gcc. This is true even if I log in and log out.

[GDH-gentoo]

However, I just tried it, and DiskFit still runs even if I've eselected for the newer gcc. This is true even if I log in and log out.

eselect gcc set adds a file in /etc/ld.so.conf.d that tells the dynamic linker to search for libgfortran in /usr/lib/gcc/$CHOST/<selected GCC version>. It is possible that the location of the libgfortran from GCC 6.5.0 has been cached, and that's why DiskFit works even if you have GCC 10.2.0 selected. Look at the output of ldconfig -p | grep libgfortran.

[jyoung]

The output of

Code: Select all

ldconfig -p | grep libgfortran.

looks like

Code: Select all

	libgfortran.so.5 (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5
	libgfortran.so.5 (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/32/libgfortran.so.5
	libgfortran.so.3 (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.5.0/libgfortran.so.3
	libgfortran.so.3 (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.5.0/32/libgfortran.so.3
	libgfortran.so (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so
	libgfortran.so (libc6,x86-64) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.5.0/libgfortran.so
	libgfortran.so (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/32/libgfortran.so
	libgfortran.so (libc6) => /usr/lib/gcc/x86_64-pc-linux-gnu/6.5.0/32/libgfortran.so

Okay, so if I understand this right I would probably need to run ldconfig on the directory that contains this library essentially any time that I do something that flushes the cache, right?

[GDH-gentoo]

Okay, so if I understand this right I would probably need to run ldconfig on the directory that contains this library essentially any time that I do something that flushes the cache, right?

I think so, yes. Or use eselect gcc set to temporarily switch to 6.5.0.

[jyoung]

Hmm, that's certainly a workable solution, but not ideal. I'm the admin on this system, but other users run DiskFit. What's the standard solution for legacy code support?

[GDH-gentoo]

Virtual machines / containers / chroots replicating the "old" environment I suppose, but in this case, copying the libgfotrtan of GCC 6.5.0 to /usr/local/lib64 with the name libgfortran.so.3 might work. I believe that, unlike /usr/lib/gcc/x86_64-pc-linux-gnu/6.5.0, the dynamic linker does search /usr/local/lib64 for shared libraries, Portage will not touch /usr/local, and the libgfortran from newer versions of GCC will have a name of the form libgfortran.so.x with x >= 5, so there will be no confusion about which version a running program will load.