MIRIAD Installation Problems
If you have installed from source and have seen a line such as
installed 304/344 programs
something really bad has happened. Most likely during building or linking a common error occured for each problem. You can look in the logfiles in $MIR/tmp or try and compile a program to see it directly on the screen:
mirboss mir.subs fitsio mir.prog itemize
and see if any of the common problems below fit the description:
Login shell problem
Although your login shell (echo $SHELL) can be bash, some shell scripts are written in csh, so you need that one as well. You probably need to make sure your C and Fortran compiler are from the same "vendor", so you don't wind up using /usr/bin/gcc and /usr/local/bin/gfortran (a common issue on Mac's). That's more likely a $PATH issue, where you just need to edit the .cshrc or .bashrc shell startup file and open a new shell to redo what you did before. On MacOSX this has caused so much confusion, that it warrented a special MacOSXLoginShell page.
If you get the not-too-uncommon error
g77: command not found
you obviously don't have the right fortran compiler. Check if your system came with gfortran instead of g77. If so, add the
command line argument to the install.miriad or test_a_new_miriad_cvs script. If not, did you really read the requirements page?
If you see a command such as:
gcc: error trying to exec 'as': execvp: No such file or directory.
you probably didn't install enough of the development tools. On a mac this means Xcode was not properly installed.
A common problem is with SELinux, which requires shared libraries to be given extra permission. The error message you might see is:
xxx: error while loading shared libraries: $MIRLIB/libmir.so: cannot restore segment prot after reloc: Permission denied. Two solution:
1) edit /etc/selinux/config (as root, or use a GUI system tool) and disable SELinux. Reboot is needed, and this can only cause an extra overhead and long wait :-(
2) use the chcon command to enable a shared library,e.g.
chcon -t texrel_shlib_t $MIRLIB/libmir.so
As just seen on an ubuntu system:
imgen: error while loading shared libraries: libcpgplot.so.5: cannot open shared object file: No such file or directory
could this be an interaction between our PGPLOT library and a system installed version? Maybe LD_LIBRARY_PATH is wrong? Check if you have /usr/lib/libcpgplot.so*
Missing header files problem
Many workstation installation of linux and mac will install runtime libraries, but skip over the development version of these packages. In order to compile them, you will need them.
xpanel.c:89:25: error: X11/Xaw/Box.h: No such file or directory
fedora 9: libXaw-devel ubuntu 8.10: libaw7-dev
Commands like rpm -qf `locate X11/Xaw/Box.h` on an RPM based system, and dpkg -S `locate X11/Xaw/Box.h` on a DEB based system will help you find out what package a particular file belongs to.
- A common problem is a missing driver. Here is a recipe to enable a driver that you know will work:
edit $MIRLIB/drivers.list <--- (un)comment the drivers you want to include/exclude mirboss mir.install pgplot
When shared libraries are used, this is usually enough, all programs that use PGPLOT should now know about the new driver set. Use device=\? to view the active list.
- another common problem is that the X development files (include files such as Xos.h etc.) were not installed on your system. This is covered elsewhere on this page. You will most likely see that MIRIAD programs do not compile and complain about a missing -lpgplot
- older versions of gfortran cannot deal with the GIF drivers (see also next item). Fix it this way:
cd $MIRLIB emacs drivers.list -> comment out the two GIDRIV lines mirboss mir.install pgplot -> check if you have libpgplot* files in $MIRLIB mir.install prog
and you should now have a working miriad again (after rehash)
- on 64bit machines some drivers (notably the GIF driver) do not work. If you installation produces a seg fault, do the following:
cd $MIR/borrow/pgplot/drivers ./fix64bit.csh mirboss mir.install pgplot
and your shared library is updated. If you don't use shared libraries, all programs would have to be relinked as well (normally not needed)
- on one particular Mac 10.5 machine strange linking problems went away when this user was using a FINK based version of pgplot in the following way:
rm $MIRLIB/libpgplot.* cd $MIR install/install.miriad pgplot=0
hkmiriad is a hacked mostly-C based set of miriad programs that you can find in $MIR/src/spec/hkmiriad. It has been written by Jin Koda (caltech).
The old style install essentially uses this:
cd $MIR/borrow/zeno make miriad_install cd $MIR/src/spec/hkmiriad cp Makefile.hk Makefile make miriad_install
A common problem is the linking of fortran and C. If you have used the old-style install, there will be a Makefile in $MIR/install that contains the FLIBS= macro. Edit the Makefile in $MIR/src/spec/hkmiriad and replace the simple value for FLIBS (-lg2c) to be the more complex one. An example could be something like
FLIBS = -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s
Currently there is no support to install this in the new build system.
Other Common Problems
If you install from source, two of the most common problems for failure are:
- a missing or wrong fortran compiler. As of this writing g77 is still the default, but newer versions of gfortran now know how to build pgplot and no patching is needed anymore (except the keyword gfortran=1 to the install.miriad script). Different distros will hide the fortran compiler in perhaps not the most logical places (not to mention package names can change):
- fedora: compat-gcc-34-g77 or gcc-gfortran
- missing (X11) development packages. On linux your package manager should be queried for these. Unfortunately not each linux distribution (or even version) will use the exact same name for this. A common example is the X11 development package. For example pgplot will need a file /usr/include/X11/Xos.h (it could also live somewhere else). The Xaw library is less important, but needed for xmtv/xpanel. Search for /usr/include/X11/Xaw/Simple.h (again,it could live somewhere else).
- fedora 7: xorg-x11-proto-devel-7.2-9.fc7, libXaw-devel
- ubuntu 8.04: x11proto-core-dev, libx11-dev, libxaw-dev
- ubuntu 12.04: x11proto-core-dev, libxaw7-dev
- mandrive 2008: libxorg-x11-devel
- mandrake 10.1: libxorg-x11-devel-6.8.2-0.5mdk
- on 64bit ubuntu8.04 here's a report on how to fix the system, where the libXaw library was 'missing', and also includes an example of installing some missing system tools. The "dev" version of a package is supposed to do this,but on this system the fix was easy:
cd /usr/lib ; ln -s libXaw7.so.7 libXaw.so apt-get install gfortran apt-get install g++ cd /usr/local/miriad_cvs ./autogen.sh ./configure --prefix=`pwd`/build F77=gfortran make make install
- the new build system has not been thoroughly tested. A common problem is with autogen.sh that results in a make that ends disappointingly as follows:
make: *** No rule to make target `install'. Stop. make: Leaving directory `/algol1/teuben/miriad/auto/miriad/borrow/pgplot' make: *** [install-recursive] Error 1
- the new build system may fail on latex building the manuals. If so, use 'make -i' instead.
- if you try to compile a program and you see some error message like this:
/usr/bin/ld: cannot find -lpgplot
most likely you have missing components on your system. Missing header file you might see. It means you did not install the development software for X11 on your system. It's one of the requirements. If this happens on a mac, go install Xcode. On linux you'll need to install the X development packages, as describe earlier on this page.
- Missing files: what package does it belong to?
This is a common situation. You might see a compiler complain about a missing header file, but your friend has this file, but not you... Depending on the type of Linux distro (sorry, for Mac you're SOL here) here's a neat trick:
rpm -qf /usr/include/X11/Xos.h (for Redhat, Fedora, Suse etc.) xorg-x11-proto-devel-7.4-14.fc11.noarch dpkg -S /usr/include/X11/Xos.h (for Debian, Ubuntu etc.) x11proto-core-dev
after you have identified the package name, they can be installed via the appropriate GUI tool, or on the commandline
yum install xorg-x11-proto-devel (for a Redhat derivative) dpkg -i x11proto-core-dev (for a Debian derivative, as well as:) dpkg -i libX11-dev
If you need to get a (sorted) listing of all the packages in your distro, here's one way
rpm -qa | sort > packages-all.list dpkg -l > packages-all.list
It is not uncommon to find over 2000 packages in this list.
Mac OS X
Although the modern Mac is running a "unix" variant, there are some issues you should be aware of. Certainly make sure your requirements are met (i.e. you have compilers installed, some developer tools are present, etc.etc.). Here are some helpful notes if you get stuck building from source:
- Peter Williams' installation notes (2007, for 10.4)
- Ramprasad Rao's notes (2003/2004 for 10.2 and 10.3)
- Peter Teuben's notes (has other links)
- [MAYBE SOLVED] some linker issue on Ubuntu 7? The same error also occurs on Ubuntu 8.04 and 9.04 !!
% mir.prog itemize ... /usr/bin/ld: /home/ijlee/miriad/bin/linux/itemize: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status
The problem appears to be that g77 (a gcc3 derived product) is linked with gcc4. Although this is not a problem on e.g. Fedora, on Ubuntu it is. Solution is to use gfortran instead. In the old-style install, simply pass gfortran=1 to the install script, viz.
In an update 9.04 version of Ubuntu we could not solve this. From googling there appears some indication that one should use
gcc -shared gfortran -shared
instead, but that didn't help either. In the end, in this case, the new-style install worked.
A similar error cropped up in Ubuntu 10.10 where the conversion from libmir.a to libmir.so would fail with a message
undefined reference to `__stack_chk_fail_local'
this was fixed by manually adding -fno-stack-protector to both the Coptions in $MIR/bin/localsys/compiler.linux, as well as fixed in CVS.
- in debug compile mode (setenv MIRDEBUG 1) on a mac you can get linking errors (can't find atom for N_GSYM stabs...).
- the new build cannot be easily relocated using the install/make_miriad_starts script
If you are activating the new build, i.e.
ln -s build_new build install/make_miriad_starts source miriad_start.csh
there are variables in automiriad.csh that have an absolute path and are not derived from $MIR. You will have to fix these manually. That includes a reference to PGPLOT variables in the pgplot-config.csh file.
- on a mac (10.5.6) all programs with uvio are now doing bus error. (reported: Bolatto May 2009)