Installation problems

From CARMA
Jump to: navigation, search

Contents

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.

Compiler problem

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

 gfortran=1

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.

Runtime problem

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


Shared library problems

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

will need

  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.

PGPLOT problems

  • 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)

 mir.install prog
  • 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 problems

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[1]: *** No rule to make target `install'.  Stop.
 make[1]: 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:

Unsolved problems

  • [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.

  install/install.miriad gfortran=1

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)
Personal tools