octave broken libgfortran.so.3: cannot open shared object file

shubhajeet · 2017-06-03 12:48:16

I updated my archlinux and now I cannot open octave. I am getting following error:

/usr/lib/octave/4.2.1/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory

I dont know why this dependency was removed on update.

Allan · 2017-06-03 13:04:43

If you have done a full update and still have this issue, you will have an AUR package replacing something in the dependency chain. Probably openblas.

shubhajeet · 2017-06-03 13:23:16

ranned this sudo find / -name libgfortran.so.3

/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgfortran.so.3

looks like libgfortran.so.3 is there but it is not finding it.

Allan · 2017-06-03 13:28:11

Nothing on your system should be linking to that (unless you specifically built something using gcc5). The current gcc version has a different library version and everything in the repos is built against that.

You either need to:
1) do a full update, or
2) rebuild an AUR package that is replacing a repo one (e.g. openblas)

Lone_Wolf · 2017-06-03 16:48:07

That file comes from gcc5 package and is only used by cuda.

shubhajeet, post output of pacman -Qs gcc please.

ireng · 2017-06-03 17:07:23

Allan wrote:

Nothing on your system should be linking to that (unless you specifically built something using gcc5). The current gcc version has a different library version and everything in the repos is built against that.
You either need to:
1) do a full update, or
2) rebuild an AUR package that is replacing a repo one (e.g. openblas)

My suggestion is rebuild octave-gui

Last edited by ireng (2017-06-03 18:10:25)

lardon · 2017-06-03 17:51:21

I've had a similar problem with R today. People are telling me it's all fine and my system is broken, which is probably the case. But I thought I'd mention it here in case someone else has the same problem.

Rebuilding the R package solved it. Perhaps rebuilding the octave package would solve yours? (Although I don't think I have the gfortran.so.3 lib on my system).

Edit: just tried with a clean docker container. It works, so I guess that confirms the problem is somehow related to my system.

Last edited by lardon (2017-06-03 18:32:37)

Scimmia · 2017-06-03 22:54:28

Again, octave isn't the problem, the same way r isn't the problem. You can use lddtree from the pax-utils package to help track down what's actually linked to the old lib.

dp · 2017-06-07 19:41:23

Scimmia wrote:

Again, octave isn't the problem, the same way r isn't the problem. You can use lddtree from the pax-utils package to help track down what's actually linked to the old lib.

[damir@Hydroximoron ~]$ lddtree /usr/lib64/R/bin/exec/R
/usr/lib64/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
    libR.so => /usr/lib/R/lib/libR.so
        libblas.so.3 => /usr/lib/libblas.so.3
            libgfortran.so.3 => None
            libatlas.so => /usr/lib/libatlas.so
        libm.so.6 => /usr/lib/libm.so.6
        libreadline.so.7 => /usr/lib/libreadline.so.7
            libncursesw.so.6 => /usr/lib/libncursesw.so.6
        libpcre.so.1 => /usr/lib/libpcre.so.1
        liblzma.so.5 => /usr/lib/liblzma.so.5
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
        libz.so.1 => /usr/lib/libz.so.1
        librt.so.1 => /usr/lib/librt.so.1
        libdl.so.2 => /usr/lib/libdl.so.2
        libicuuc.so.59 => /usr/lib/libicuuc.so.59
            libicudata.so.59 => /usr/lib/libicudata.so.59
            libstdc++.so.6 => /usr/lib/libstdc++.so.6
            libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
        libicui18n.so.59 => /usr/lib/libicui18n.so.59
        libgomp.so.1 => /usr/lib/libgomp.so.1
    libpthread.so.0 => /usr/lib/libpthread.so.0
    libc.so.6 => /usr/lib/libc.so.6
[damir@Hydroximoron ~]$ pacman -Qo /usr/lib/libblas.so.3
/usr/lib/libblas.so.3 ist in atlas-lapack-base 3.10.3-1 enthalten

i am now rebuilding atlas-lapack to fix this for me

Trilby · 2017-06-07 19:45:51

So, just like predicted, you had an AUR package that replaced a repo package.

I'm a bit surprised by how many people need to use lddtree* to investigate their tools to identify an AUR package that has replaced a repo package on their system. Is there some AUR fairie running around replacing software on arch users' computers without their knowledge? Perhaps it's like those old Folgers Crystals ads: "we've secretly replaced this archer's packages with AUR builds. Let's see if they can tell the difference."

(*although it is a useful tool I only recently learned of - thanks Scimmia)

dp · 2017-06-07 19:57:11

Trilby wrote:

I'm a bit surprised by how many people need to use lddtree* to investigate their tools to identify an AUR package that has replaced a repo package on their system. Is there some AUR fairie running around replacing software on arch users' computers without their knowledge? Perhaps it's like those old Folgers Crystals ads: "we've secretly replaced this archer's packages with AUR builds. Let's see if they can tell the difference."

no, sometimes the standard package is simply not specific enough for a task and one needs to exchange parts to have it running how one wants it running. this is the original reason of ArchLinux!

blas lapack cblas are all in repos as standard options
if one wants to run atlas-lapack, one needs to compile it optimised for the system used on - this approach also replaces the pkgs from repos. the only annoying thing is, that AUR are not taken care so often and the recompiling against newer libs happens later - so people run into issues. but hey, we are human, we are arch, we learn and know it for next time. this is why i originally posted here (after long time again )

dp · 2017-06-07 19:58:52

side-remark: this is by no means a critique to the AUR maintainers! it just needs to be more of them, so that pkg rebuilds are triggered faster (namcap automation, anyone? )

Trilby · 2017-06-07 20:02:47

Eh ... you are reponsible for rebuilding your AUR packages on ABI changes, not the package maintainer.

dp · 2017-06-07 20:17:53

i am - but the package maintainer needs to addapt the dependencies in the PKGBUILD

Trilby · 2017-06-07 20:33:11

There are no versioned dependencies in the PKGBUILD.

seth · 2017-06-07 20:37:20

ftr, dp isn't the OP - we don't yet know about shubhajeet's problem (though it will be some AUR package)

I don't know how (yes - it will be yaourt. swallow it...) works, but guess an artificial update of the package would trigger a rebuild on (?) "yaourt -Syu", so the maintainers probably *could* do something (what does still *not* resolve anyone from his or her responsibility)

Btw: everytime you call "pacman -Qm" a fairy dies ;-)

V1del · 2017-06-07 20:40:46

Yeah the AUR maintainers could bump the pkgrel to trigger a rebuild/update for AUR helpers, few are THAT active for simple soname bumps though.

dp · 2017-06-07 20:46:03

indeed! but keep also in mind, this was a big bump on libfortran, not used by the masses but rather by people who need it or tools which need it. version bumps will follow in time

Arch Linux

#1 2017-06-03 12:48:16

octave broken libgfortran.so.3: cannot open shared object file

#2 2017-06-03 13:04:43

Re: octave broken libgfortran.so.3: cannot open shared object file

#3 2017-06-03 13:23:16

Re: octave broken libgfortran.so.3: cannot open shared object file

#4 2017-06-03 13:28:11

Re: octave broken libgfortran.so.3: cannot open shared object file

#5 2017-06-03 16:48:07

Re: octave broken libgfortran.so.3: cannot open shared object file

#6 2017-06-03 17:07:23

Re: octave broken libgfortran.so.3: cannot open shared object file

#7 2017-06-03 17:51:21

Re: octave broken libgfortran.so.3: cannot open shared object file

#8 2017-06-03 22:54:28

Re: octave broken libgfortran.so.3: cannot open shared object file

#9 2017-06-07 19:41:23

Re: octave broken libgfortran.so.3: cannot open shared object file

#10 2017-06-07 19:45:51

Re: octave broken libgfortran.so.3: cannot open shared object file

#11 2017-06-07 19:57:11

Re: octave broken libgfortran.so.3: cannot open shared object file

#12 2017-06-07 19:58:52

Re: octave broken libgfortran.so.3: cannot open shared object file

#13 2017-06-07 20:02:47

Re: octave broken libgfortran.so.3: cannot open shared object file

#14 2017-06-07 20:17:53

Re: octave broken libgfortran.so.3: cannot open shared object file

#15 2017-06-07 20:33:11

Re: octave broken libgfortran.so.3: cannot open shared object file

#16 2017-06-07 20:37:20

Re: octave broken libgfortran.so.3: cannot open shared object file

#17 2017-06-07 20:40:46

Re: octave broken libgfortran.so.3: cannot open shared object file

#18 2017-06-07 20:46:03

Re: octave broken libgfortran.so.3: cannot open shared object file

Board footer