When I open emacs I am getting this warning
external/slc6_amd64_gcc630/lib/libtiff.so.5: no version information available (required by emacs)
I recently changed my system from sl6 to centos7. So, it is a result of this. How do I resolve this issue?
Just a guess, but I think you could get away with a symlink from your libtiff to the location expected by your emacs binary (assuming you don't just want to recompile / get an emacs binary for your distro).
Make a link to your libtiff wherever it may be,
find /usr/lib -name libtiff.so.5 2>/dev/null
or locate libtiff.so.5
from that expected by the emacs binary,
ldd /usr/bin/emacs | awk '/libtiff/ { print $3 }'
replacing the /usr/lib/, /usr/bin/emacs with your actual locations.
Related
Original Question
I am having trouble installing gtk to start building GUIs in C++ on Code::Blocks. Could anyone nudge me in the right direction? I'm running Windows 10 (64-bit) on a Lenovo.
I attempted an installation guide (https://www.youtube.com/watch?v=jvQXvTtSIQo), stack overflow (How do you install GTK+ 3.0 on Windows?), the official GTK installation guide (https://www.gtk.org/download/windows.php), a written guide (http://www.tarnyko.net/repo/gtk3_build_system/tutorial/gtk3_tutorial.htm), and just noticed a very similar stack overflow (Install GTK for c on Windows 10?)
Before this, my PATH environment variable only recorded C:\Users\Owner\AppData\Local\Microsoft\WindowsApps;C:\Users\Owner\AppData\Roaming\npm;C:\Users\Owner\AppData\Local\atom\bin;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;
I downloaded MinGW from mingw.org. This was to the youtube link's comment that the official is more stable than the one that can be installed with Code::Blocks. I added C:\MinGW\bin to PATH.
Trying the official GTK installation site, I downloaded MSYS2 and used pacman -Syu to install core system packages and pacman -Su to then update. That's the end of that, so I think gtk is officially installed, I just need to get it to talk to Code::Blocks. I added C:\msys64\mingw64\bin to PATH but that didn't seem to work.
I tried to install the all-in-one bundle for GTK 3.6.4 at http://www.tarnyko.net/dl/gtk.htm , and extracted it to C:\gtk. I now have C:\gtk\bin in PATH. GTK should be in my path in one form or the other. I can run gtk3-demo and gtk-demo-application from CMD but not MSYS2. I'm a bit confused about that. It probably has something to do with MSYS2's specific path variable, I think? But it should search the system's PATH afterward? And I don't know how to change that specific path? Probably questions for another day.
So the similar stack overflow, youtube, and written tutorial all say to use pkg-config --cflags --libs gtk+-3.0 to check for a reasonable output to see if I have gtk correctly installed. I installed
pkg-config-lite to avoid the glib circular dependency issue that How to install pkg config in windows? describes and frankly I do not understand. I added it to C:\MinGW\bin to by in my path. Now I am able to run it, but get:
Package gtk+-3.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-3.0' found
I tried 3.6.4 instead of 3.0. No dice. I tried just 3. Nope. I can only find gtk3 files, and not the actual version I installed anywhere. pkg-config --cflags --libs says that I need to name a library, so I tried just gtk hopiing to get libraries containing that. Nope. The rest of the tutorials are aimed at getting Code::Blocks compiler (I think) to include gtk. I hope this is the only obstacle, and I will be able to get the rest. But, if anyone can help me through the rest, it would be appreciated.
At this point I'm out of ideas. Can someone help me?
Gratefully,
John
More Questions After Liberforce's Answer
Thank you for writing up https://www.gtk.org/download/windows.php !! I bet it helps a lot of frustrated newbies like myself. I will kindly offer more proper feedback after I get everything to work. I am stuck on compiling a C/C++ program, if you can help more. Before I get to that, I want to be very clear about the precise steps I took. The step names correspond to your written instructions.
Step 1: Install MSYS2
Alright, resetting everything...
Removed C:/gtk directory from PATH and from computer, aka all the tarnyko files.
Removed C:/MinGW directory from PATH and from computer, effectively uninstalling. I read your conversation with Simon (Unable to compile code with GTK and https://chat.stackoverflow.com/rooms/156828/discussion-between-liberforce-and-simon) about the confusion between MinGW's terminal which includes msys1.0 and MSYS2 terminal which includes MinGW. I figured this would be safer.
Thus, I only have C:\msys64 in PATH (and what I had before, irrelevant to GTK).
Uninstalled MSYS2 (via Add/Remove Programs) and reinstalled using the x86_64 from www.msys2.org. On pacman -Syu, I received error, "msys2-runtime and catgets are in conflict" and "msys2-runtime and libcatgets are in conflict." Entered y to remove both.
I keep uninstalling and reinstallling but I hit the following problem... (5/5) upgrading pacman was at 100% and the warning pops up:
warning: terminate MSYS2 without returning to shell and check for updates again
warning: for example close your terminal window instead of calling exit
The program halts here. I assume this means to close the window. I did, and clicked OK for the dialogue "Processes are running in session: Close anyway?." Window now printed "Hangup signal received" and it is no longer responding. I use task-manager to kill it.
Openning MSYS2 by the desktop application after the first pacman -Syu gave me the dialogue to choose which shell: MSYS2, Mingw-w64 32 bit, Mingw-w64 64 bit. I instead went into the filesystem and openned C:\msys64\msys2_shell.cmd for all future instances.
Ran pacman -Syu to finish installing packages. I restart MSYS2 again, and ran pacman -Su to reveal
:: Starting core system upgrade...
there is nothing to do
:: Starting full system upgrade...
there is nothing to do
pacman -Syuu showed:
:: Synchronizing package databases...
mingw32 is up to date
mingw64 is up to date
msys is up to date
The pacman -Su, pacman -Sy, and pacman -Suu likewise reveal everything okay. Closed and reopenned C:\msys64\msys2_shell.cmd
pkg-cofig just gives "bash: pkg-config: command not found." So I ran pacman -S pkg-config and got that working. update-core, though, which is mentioned in https://github.com/msys2/msys2/wiki/MSYS2-installation cannot be found, and pacman -S update-core will not work. pacman -Ss core turns up:
msys/coreutils 8.26-2 (base) [installed]
The basic file, shell and text manipulation utilities of the GNU operating
system
And other files that seem unrelated. Results of pacman -Ss core likewise seem irrelevant.
pacman --version shows:
.--. Pacman v5.0.1 - libalpm v10.0.1
/ _.-' .-. .-. .-. Copyright (C) 2006-2016 Pacman Development Team
\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet
'--'
This program may be freely redistributed under
the terms of the GNU General Public License.
Ran "pacman --needed -S bash pacman pacman-mirrors msys2-runtime" to reveal:
warning: bash-4.4.019-2 is up to date -- skipping
warning: pacman-5.0.1-5 is up to date -- skipping
warning: pacman-mirrors-20160112-1 is up to date -- skipping
warning: msys2-runtime-2.10.0-2 is up to date -- skipping
there is nothing to do
I exited out of all msys shells, and ran C:\msys64\autorebase.bat, although not on a 32 bit system. I believe there is a typo when it says to reopen msys2_shell.bat, which I do not have. I openned msys2_shell.cmd. I use pacman -Suu once more to reveal that everything is okay.
Step 2 -> Step 5 (optional): Install build tools
Openned C:\msys64\msys2_shell.cmd and ran "pacman -S mingw-w64-x86_64-gtk3" (GTK+3 package) and "pacman -S mingw-w64-x86_64-toolchain base-devel" (package to develop GTK+3 applications in other languages) (defaulted to all installations when prompted).
Failed to Compile a GTK+3 Application
Restarted computer. Openned C:\msys64\msys2_shell.cmd. Following https://developer.gnome.org/gtk3/stable/gtk-getting-started.html.
Put the simple window tutorial file in C:\Users\Owner\Desktop\test_code\example-0.c . When running gcc pkg-config --cflags gtk+-3.0 -o example-0 example-0.c pkg-config --libs gtk+-3.0 , got the error in my original question. Used "pacman -Ss gtk3" to see two packages I think I need. Ran "pacman -S mingw-w64-x86_64-gtk3 mingw-w64-x86_64-gtkmm3" .
To answer your questions to Simon about this same error at Unable to compile code with GTK , pkg-config --list-all | grep gtk returns nothing, even after closing and reopenning C:\msys64\msys2_shell.cmd. "which gcc" returns:
which: no gcc
in(/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:
/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:
/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
I see gtk-3.0 under C:\msys64\mingw64\include. I have no idea how to add this to the path. "echo $PKG_CONFIG_PATH" returns:
/usr/lib/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig
Correctly Compiled a File in Console with GTK+3
Checked that GTK was in Console
I needed to open up MSYS2 in a Mingw-w64 64 bit shell. This can be preformed via the Desktop app for MSYS2 which prompts you which one of three shells you want to open: MSYS2, Mingw32, and Mingw64. Specifically, me installing gtk with the command mingw-w64-x86_64-toolchain means it can only be accessed this way.
Commands in this shell show that I do, in fact, have gtk:
$ pkg-config --modversion gtk+-3.0 --> 3.22.29
$ which gcc --> /mingw64/bin/gcc
Compiled Sample Code from Mingw64 Console
I referenced https://github.com/msys2/msys2/wiki/MSYS2-introduction to learn the file system / drive mounting syntax. I will place the sample code gotten from https://developer.gnome.org/gtk3/stable/gtk-getting-started.html in `/c/Users/Owner/Desktop/test_code/example-0.c'. I just used my favorite IDE, Atom, but any text editor would do.
Openned MSYS2's Mingw64 shell, cd /c/Users/Owner/Desktop/test_code/ , compiled with gcc \pkg-config --cflags gtk+-3.0` -o example-0 example-0.c `pkg-config --libs gtk+-3.0`` , and execute with ./example-0
Unsuccessful to Link GTK+3 and the Code::Blocks Compiler
I Understand some Linker Settings
I went into Code::Blocks. Went to Settings > Compiler... Made sure to use the dropdown box under Selected compiler to select GNU GCC Compiler, and clicked Reset Defaults because of complications when I first installed Code::Blocks. The check boxes under Compiler Flags should all blank after the reset, and so I checked "Have g++ follow the C++14 ISO C++ language standard [-std=c++14]" under General and "Enable all common compiler warnings (overrides many other settings) [-Wall]" under Warnings.
Next to where it says Compiler Flags, I went to Linker settings and added text to Other linker options. I got this text by running pkg-config --cflags gtk+-3.0:
-mms-bitfields -pthread -mms-bitfields -IC:/msys64/mingw64/include/gtk-3.0 -IC:/msys64/mingw64/include/cairo -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/pango-1.0 -IC:/msys64/mingw64/include/fribidi -IC:/msys64/mingw64/include/atk-1.0 -IC:/msys64/mingw64/include/cairo -IC:/msys64/mingw64/include/pixman-1 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/freetype2 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/harfbuzz -IC:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include/gdk-pixbuf-2.0 -IC:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include -IC:/msys64/mingw64/include/glib-2.0 -IC:/msys64/mingw64/lib/glib-2.0/include -IC:/msys64/mingw64/include -LC:/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lz -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -lfribidi -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl
Explanation: When compiling from console, I used a command that included the text /pkg-config --cflags gtk+-3.0`` . The backticks mean to run pkg-config --cflags gtk+-3.0 BEFORE the higher-level compilation command, and insert whatever text comes out into the higher-level compilation command. Code::Blocks needs that text under the Linker settings.
I do not Understand the Search Directories
In Settings > Compiler... , beside where it says Compiler Settings, I clicked Search directories. I know you need to do some work here. After this, you go back to Linker Settings to finish, and your Code::Blocks will be ready to go!
If anyone can help me here, or if I figure it out, I would love to finish, in case this helps posterity. I have GTK compiling, and that is good enough for now.
Ok, let's start from the beginning.
Don't use tarnyko packages, they're outdated and not maintained anymore
Official way to get GTK+ 3 on Windows is through MSYS2
Don't blindly follow every guide you find on the internet, mixing them all together and expect things to work. Things change, and something that was advertised at some point can be outdated and plain wrong at the time you read it. If you cook a dish with 3 different recipes at the same time, don't expect it to taste good.
So:
Remove all remnants of the tarnyko bundle
Remove pkg-config-lite. pkg-config is already installed through MSYS2 if you follow official installations
Try to get things working with the MSYS2 guide (pkg-config detection, and compiling a simple GTK+ program) without the Code::Blocks integration first
Once this works, making it work on Code::Block should be a matter of setting some environment variables and pointing to the right pkg-config.
I used gtk+ bundle_2.24.10 32 bit on Windows 7.
I downloaded it from tarnkos, there's no need to do change a single setting in code blocks 17.12.
I am trying to compile matconvnet-1.0-beta20 with Matlab 2016a on Ubuntu 16.04. Initial phase of compilation works fine:
untar('http://www.vlfeat.org/matconvnet/download/matconvnet-1.0-beta20.tar.gz') ;
cd matconvnet-1.0-beta20
run matlab/vl_compilenn
The error happens when I run vl_simplenn(network, image) which gives following error:
Invalid MEX-file '/home/matconvnet-1.0-beta20/matlab/mex/vl_nnconv.mexa64':
/usr/local/MATLAB/R2016a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version
`GLIBCXX_3.4.21' not found (required by /home/matconvnet-1.0-beta20/matlab/mex/vl_nnconv.mexa64)
To understand the cause of problem, I run /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC which doesn't give any output bash: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: Permission denied
Also more /usr/lib/x86_64-linux-gnu/libstdc++.so.6 gives no output:
******** /usr/lib/x86_64-linux-gnu/libstdc++.so.6: Not a text file ********
I did some research and found some possible solutions:
http://it.mathworks.com/matlabcentral/newsreader/view_thread/162466
The problem is that MATLAB secretly changes LD_LIBRARY_PATH on startup
to point to the MATLAB version of GLIBC++, so that GLIBC++ 3.4.9 can
no longer be found. The solution is to modify matlab/bin/.matlab7rc.sh
so that "LDPATH_PREFIX" contains the path to the version of GLIB
installed with your compiler, then this is found before the
matlab-supplied library.
so I edited /usr/local/MATLAB/R2016a/bin/.matlab7rc.sh and modified LDPATH_PREFIX='' in 195th line to LDPATH_PREFIX='/usr/lib/x86_64-linux-gnu'.
After applying this change, the problem still exist.
As suggested here, I copied .matlab7rc.sh to current working directory of project, but still error persist.
https://askubuntu.com/questions/719028/version-glibcxx-3-4-21-not-found
According to first answer, running this command
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6
gives an error:
ln: failed to create symbolic link 'usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6': No such file or directory
Seems like second solution suggests changes of LD_PRELOAD path in .matlab7rc.sh, but it is not anywhere inside the file.
How to tell mex to link with the libstdc++.so.6 in /usr/lib instead of the one in the MATLAB directory?
From Matlab directory in /usr/local/MATLAB/R2016a/bin$ I run
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/libstdc++.so.6
but the problem still exist.
Maybe there I didn't apply the solution in the correct way Or maybe there is another solution elsewhere that I didn't find. Please let me know, I am very confused!!!
You need before execute (matlab in my case) add path of library:
In console execute this:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 matlab
I had the same problem.
In my case, to solve it, I first ran "locate" to list all the possible versions of the library in the system.
locate libstdc++
As an example, I report the result on my system
I then set the most recent version of "lib" by exporting the environment variable:
export LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21"
So, the fullpath of the library to be set depends on where it is allocated in your system.
There are 2 possible solutions:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/libstdc++.so.6
Install this package:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
MAYBE the second solution you mentioned really works, but you have done it before. So you cannot operate in the same way again because you have ever linked /usr/lib/x86_64-linux-gnu/libstdc++.so.6 to usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6. TRY rebooting?
Also, you use MATLAB R2016a, but this command applies to R2014a. Was it that you ignore this point?
I have been stuck on this problem for several weeks and been looking around on Internet for solution but so far not so good...
So I have a program written by someone else and I try to compile it in Matlab to make it work. My computer is Red-hat enterprise Linux workstation (64 bits) with gcc 4.4.3 and Matlab 2011b installed. The gcc is compatible with my Matlab (http://www.mathworks.com/support/compilers/R2011b/glnxa64.html).
The compilation works fine (I mean, no error message occurs in Matlab command window). But after compilation, every time when I use a specific function from the compilation (it's call "mexLasso"), it will show up errors like this:
***Invalid MEX-file '/usr/local/matlab_R2011b/toolbox/spams-matlab/build/mexLasso.mexa64':
/usr/local/matlab_R2011b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by
/usr/local/matlab_R2011b/toolbox/spams-matlab/build/mexLasso.mexa64)
Error in test (line 24)
alpha=mexLasso(X,D,param);*
So I type "strings /usr/lib/libstdc++.so.6 | grep GLIBC" in the terminal, and I found the "GLIBCXX_3.4.11" is actually in it.
I've been using Linux and gcc stuff for only several months...so there are still a lot of things I don't understand. It will be of great help if you can explain it in detail. Thanks!!
%% More detail:
I got these programs on machine learning from http://spams-devel.gforge.inria.fr/downloads.html. The wierd thing is, after compilation, other functions in that package works fine (such as "mexTrainDL").
The solution prompted by #whjiang works but have two limits:
You may be required a sudo privilege to change the library symbol
link.
The change is global and can affect all users
So there is another.
As explained by this answer from MATLAB Central, the problem is caused by Matlab:
Matlab internally changes the LD_LIBRARY_PATH to prefer <MatlabPATH >/sys/os/<ARCH>
and the <MatlabPATH>/sys/os/libstdc++.so.6 is out of date.
The solution is set LD_PRELOAD when calling Matlab like this,
env LD_PRELOAD=/usr/lib/libstdc++.so.6 <MatlabPATH>/bin/matlab -desktop
The path of libstdc++.so.6 my be different from os to os. For example, on my LMDE2, the path is /usr/lib/x86_64-linux-gnu/libstdc++.so.6.
This is answered in the libstdc++ FAQ: http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
Here is an solution:
sudo ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 /usr/local/MATLAB/R2011b/bin/glnxa64/libstdc++.so.6
explanation and reference:
http://fantasticzr.wordpress.com/2013/05/29/matlab-error-libstdc-so-version-glibcxx_3-4-15-not-found/
A simple solution from this page ( http://ubuntuforums.org/showthread.php?t=808045 ) that worked for me.
Go to the matlab directory where libstdc++.so.6 and libgcc_s.so.1 are stored. In my case, this was:
cd /usr/local/MATLAB/MATLAB_Production_Server/R2015a/sys/os/glnxa64
Then rename libstdc++.so.6 and libgcc_s.so.1:
sudo mv libstdc++.so.6 libstdc++.so.6.orig
sudo mv libgcc_s.so.1 libgcc_s.so.1.orig
That's it!
I am trying to open gmail with Emacs. M-x wl yields the following error message.
/usr/bin/mail is not an executable. Setting mail-interactive to t.
Initializing...
Loading mail-mime-setup...done
gnus-mime-setup is not found.
emh-setup is not found.
Updating addresses...done
Checking environment...
Auto plugged off at imap.gmail.com:993
byte-code: Searching for program: no such file or directory, gnutls-cli
Any ideas?
It wants you to install a utility called gnutls-cli. If you're on a Debian-derived distribution, apt-get install gnutls-bin which contains this utility and a few others. If you're on something else, please edit your question to include more details.
I am getting the following error when I trying to a run mex file in MATLAB:
??? Invalid MEX-file
'findimps3.mexa64':
/MATLAB/bin/glnxa64/../../sys/os/glnxa64/libgfortran.so.3: version `GFORTRAN_1.4' not found (required by /usr/lib/libblas.so.3gf)
Any ideas how to solve this problem?
update:
I found out that "strings MATLAB/.../libgfortran.so.3 | grep GFORTRAN" output GFORTRAN_1.0. I tried to changed libgfortran inside MATLAB but it didn't work. Not I think it's better to find a suitable libblas that works with GFORTRAN_1.0.
read this link, it explains how to configure matlab on some linux systems.
here the steps that are relevant to you:
To enable running external programs, […] fortran libraries need to be properly updated and linked. Look at the output of this command:
ll "$MATLABDIR/bin/glnxa64/"
It is likely that [this link] exist:
libgfortran.so.3 -> libgfortran.so.3.0.0
Search for [this library] on your machine:
locate libgfortran.so
[…] Update Matlab's links to point to these newer versions:
sudo ln -sf [location of libgfortran.so.3.0.0] "$MATLABDIR/bin/glnxa64/libgfortran.so.3"
I (think I) fixed this problem by running matlab with LD_PRELOAD, like this
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libfreetype.so:/usr/lib/x86_64-linux-gnu/libgfortran.so.3 matlab
Notice freetype was another library I was having a similar problem with.
In my case the following command worked:
sudo ln -sf /usr/lib/gcc/i686-linux-gnu/4.7/libgfortran.so /usr/local/MATLAB/R2012a/sys/os/glnx86/libgfortran.so.3
Matlab was complaining it couldn't find the GFORTRAN1.4 in the following location:
/usr/lib/gcc/i686-linux-gnu/4.7/libgfortran.so
So I linked this location to the library I had :
/usr/local/MATLAB/R2012a/sys/os/glnx86/libgfortran.so.3
I found the location of this library by using the locate command as given above:) Thanks for the help:)
In my case, fixed by
$ ln -sf /usr/lib64/libgfortran.so.3.0.0 /opt/matlab/sys/os/glnxa64/libgfortran.so.3
Errors I meet when using CDSP:
csdp: /opt/matlab/sys/os/glnxa64/libgfortran.so.3: version GFORTRAN_1.4' not found (required by /usr/lib64/atlas/libptf77blas.so.3)
csdp: /opt/matlab/sys/os/glnxa64/libgfortran.so.3: versionGFORTRAN_1.4' not found (required by /usr/lib64/atlas/libf77blas.so.3)
I just ran into the same problem (error usr/lib64/libgfortran.so.3: version `gfortran_1.4' not found) and it was actually not hard to fix. The problem seems to be that gfortran_1.4 version of libgfortran.so.3 comes from the release gcc-4.6.2 (i.e. fortran 4.6).
What I did was downloaded gcc-4.6.2 and built, using the steps: tar -xvf gcc-4.6.2.tar.gz cd gcc-4.6.2 ./contrib/download_prerequisites cd .. mkdir objdir cd objdir $PWD/../gcc-4.6.2/configure --prefix=$HOME/gcc-4.6.2 --enable-languages=c,fortran,c++,go make make install
Then, once everything was made, I went to the directory where the new, fresh libgfortran.so.3 was sitting (in my case it was /home/testuser/objdir/x86_64-unknown-linux-gnu/32/libgfortran/.libs/)
I copied this version of libgfortran.so.3, and went to the directory where my program was expecting to find libgfortran.so.3. I replaced the old one (the old libgfortran.so.3) with the new one (the one we just copied).
The problem instantly went away. I hope this helps you too!