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 ;-)
]]>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 )
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)
]]>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
]]>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.
]]>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
]]>shubhajeet, post output of pacman -Qs gcc please.
]]>You either need to:
1) do a full update, or
2) rebuild an AUR package that is replacing a repo one (e.g. openblas)