[daip] Installation feedback

[Eric Greisen]

Martin Hardcastle writes:
 > Hi folks,
 > 
 > I thought I would drop you a line to comment on my experiences during
 > the installation of 31DEC06. I decided to try to compile this myself
 > with the intel compiler (ifort (IFORT) 9.0 20051201) because of the
 > small AP size in the binary installation (as described in the
 > AIPSLetter). I now have a working installation which gives a distinct
 > improvement in speed on my AMD systems, and a top AIPSMark00 of
 > 220 (dual Opteron 250, 2.4 GHz). But it took me longer than I would
 > have expected to get everything working.

     This is a new record, easily exceeding the 180 we got on our
Intel dual Xeon 3.06 GHz box.

 > 
 > First, I tried to change the compiler to be used in install.pl . It's
 > not obvious to the user at this point that the right thing to do is
 > not specify compiler options (since FDEFAULT.SH will over-ride them
 > anyway if your compiler matches ifort). So I wasted some time trying
 > to guess sensible options.

      install.pl is not smart eneough to negotiate all the case
statement stuff

 > 
 > Once I'd done this, INSTEP2 ran OK (though in passing I note that the
 > options that you get from FDEFAULT.SH for ifort are tuned for Pentiums
 > -- architecture `W' is the best match I've found for the Opterons,
and

     Actually W is deprecated after 8.1.  The -axNP which we specify
at compile and link time should make (large) load modules which choose
the subsections of code based on architecture at run time.  These
modules make our only AMD run about 7% faster than the GNU version.

 > leaving this out can make a significant difference). But INSTEP4
 > failed at the linking stage. I was using ifort as the linker, and the
 > problem seemed to come from linking all the libraries in
 > $LIBR/*/SUBLIB : it was complaining about unresolved symbols in SUBLIB
 > libraries, although the symbols were actually there in other libraries
 > passed to the compiler at the same time. I don't know what was going
 > on here, and am inclined to blame the Intel compiler, which didn't
 > seem to be passing all its arguments to ld: however, I had to
 > hand-tune LDOPTS.SH to reproduce what should have happened with
 > ifort...
 > 
 > COMPILER="/usr/bin/ld"
 > LINK="-rpath /usr/local/intel/fc/9.0/lib -L/usr/local/intel/fc/9.0/lib  /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o /usr/local/intel/fc/9.0/lib/for_main.o -dynamic-linker /lib/ld-linux.so.2 -Bstatic -lifport -lifcore -Bdynamic -limf -lm -Bstatic -lirc -Bdynamic -lc -Bstatic -lirc_s -Bdynamic -ldl -lc /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o -lsvml"
 > 
 > This was finally enough to get things working.

    I guess I can see why the LINK is so messy given the COMPILER here
- did you fix the case statement?  The files we ship in $SYSLINUX are
the ones we use (with the compiler set to our 9.0 compiler) and it
works just fine.

     I remember hitting problems with our LIBR.DAT - some compilers
not liking the repetition of $APLSUB and $APLGEN libraries while
others require even another repetition.  I foget the circumstances
however.

Thanks for the information.

Eric Greisen

 > 
 > This isn't meant to be any sort of complaint -- I recognise that I'm
 > trying to do something off the beaten track and that most people will
 > either put up with the small AP size in the binary installation or
 > compile with g77. My major problem with the linking seems to be one
 > that I guess you haven't encountered. However, since you are using the
 > Intel compiler at NRAO, I wondered if it would be worth putting a few
 > notes on how you would do an installation from source on the web, and
 > maybe some comments on the choice of compiler options?
 > 
 > Regards,
 > 
 > Martin
 > 
 > _______________________________________________
 > Daip mailing list
 > Daip at listmgr.cv.nrao.edu
 > http://listmgr.cv.nrao.edu/mailman/listinfo/daip