Hi,
On Thu, Feb 25, 2010 at 10:29:18PM -0500, Jason Swails wrote:
> On Thu, Feb 25, 2010 at 10:04 PM, case <case.biomaps.rutgers.edu> wrote:
> > On Thu, Feb 25, 2010, Jason Swails wrote:
> >>
> >> A fresh checkout of Amber11 is giving the following errors when
> >> compiled with intel compilers and intel MKL (linux em64t):
> >
> > Sigh...I am really looking forward to changing to git. There have been
> > something like 75 CVS commits today, so saying something like "a fresh
> > checkout of Amber11" is only mildly helpful. Once we make the change, you
> > can specify an exact commit that I can be sure to reproduce.
When there is a flury of commits, the best testing strategy is to wait
for the storm to pass; if committers are not careful with the timing
and the order of their commits then the repository may easily pass
through an unstable state compile-wise.
With cvs one can use date stamps; so if one cvs updates and then makes
from src/ the 'Starting installation of...' stamp can be used to reproduce
the likely cvs state.
For powerusers:
alias a alias
a cvsld 'cvs log -d "\!*" | less "+G?selected revisions: [1-9]"'
#cvs log -d "04/10/2003>03/31/2003" | less '+G?selected revisions: [1-9]'
> >> 18:38:07 [linx64: ~] > ifort -V
> >> Intel(R) Fortran Compiler for applications running on Intel(R) 64,
> >> Version 10.1 Build 20080312 Package ID: l_fc_p_10.1.015
> >> Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
> >> 18:39:44 [linx64: ~] > echo $MKL_HOME
> >> /opt/intel/mkl/10.0.2.018/
> >
> > Be sure you have again done "cvs co"; be sure you have re-configured; then
> > post your config.h file (if the problem persists). We particularly need to
> > see what your FLIBS variable is.
> >
> >> /ufl/qtp/aer/gps/arwen_3/amber11/bin/nab -o matgen matgen.o
> > Another idea: go to amber11/src/nss and type "nab -v matgen.o". That will
> > give verbose output that should help locate the problem.
> >> /ufl/qtp/aer/gps/arwen_3/amber11/lib/libnab.a(pbsaapi.o)(.text+0x271):
> >> In function `prepb_read_':
> >> : undefined reference to `for_write_seq_lis'
> >
> > The entry point should be defined in libifcore.a in the library connected
> > to your ifort compiler. For me, this is in /opt/intel/fce/10.1.018/lib.
> > So either your FLIBS variable doesn't have "-ifcore" in it, or it's in the
> > wrong order, or the compiler is not looking in the proper directory, or....
Yes, something may be amiss with nab due to commits starting
around the 2nd week of Feb.
I have a feeling that FLIBS or some other build mechanism is
out of whack.
While testing this past weekend with pgi i got lots of weird link errors.
I switched to intel and they went away; back to pgi and they reappeared.
My plan was to reinvestigate this week, but i havent gotten to it yet. fwiw,
Things were ok:
Installation of AmberTools, version 1.3 is complete at Thu Feb 11 03:39:08 EST 2010.
pgf90 9.0-1 64-bit target on x86-64 Linux
Things were amiss:
Starting installation of AmberTools, version 1.3 serial at Sat Feb 20 01:40:22 EST 2010.
Starting installation of AmberTools, version 1.3 serial at Sun Feb 21 02:52:41 EST 2010.
Starting installation of AmberTools, version 1.3 serial at Mon Feb 22 16:38:47 EST 2010.
...
/nfs/10/srb/amber/amber11/bin/nab -c matgen.nab
/nfs/10/srb/amber/amber11/bin/nab -o matgen matgen.o
/usr/local/pgi-9.0-1/linux86-64/9.0-1/lib/libpgf90.a(initpar.o): In function `__hpf_abort':initpar.c:(.text+0xc9): undefined reference to `__hpf_abortx'
/usr/local/pgi-9.0-1/linux86-64/9.0-1/lib/libpgf90.a(initpar.o): In function `pghpf_init':
initpar.c:(.text+0xd6e): undefined reference to `__hpf_init_consts'
initpar.c:(.text+0xd77): undefined reference to `__hpf_begpar'
initpar.c:(.text+0xdd6): undefined reference to `pghpf_np_'
initpar.c:(.text+0xde2): undefined reference to `pghpf_me_'
but ok with
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 10.0 Build 20070426 Package ID: l_fc_p_10.0.023
Scott
> Ugh. It's also possible that the group member that tried compiling
> did not have their environment set (i.e. ifortvars.sh were not
> sourced, and the intel compiler libraries were not in any library
> path). I'll take a closer look at this, and we'll check out a *fresh*
> copy tomorrow morning (whatever that may be :) ).
>
> >>
> >> What's strange is that I did not get this error with the version 11
> >> intel compilers (though this is a separate checkout by someone else in
> >> our group, but it's new nonetheless).
> >>
> >
> > I don't see that there has been any change in the location of
> > for_write_seq_lis between version 10 and 11 of ifort. Also, things work for
> > me for both verion 10.1.025 and 11.1. So, I'm hoping that you just got
> > trapped in an inconsitent CVS state.
>
> He got the same errors in two *separate* checkouts today. I think his
> environment may be more to blame. We subsequently tried with the gnu
> compilers, since we figured it was a compiler issue and got an error
> when compiling ptraj. I think it had something to do with declaring i
> as an int in two for loops in the time correlation function. I took
> "int" out of the for loops, but the compile still failed (I had lost
> patience at this point and didn't pursue this much further... Also why
> I didn't devote a post to it). Maybe it has something to do with a
> possibly garbled CVS version that had already been torn through with
> ifort as part of an incomplete environment setup. Who knows.
> Tomorrow will bring new trials and hopefully brighter updates.
>
> On a side note, I had only just learned about git a week or two ago as
> one of Torvalds' *side* projects from (and for) the linux kernel. A
> mildly impressive individual...
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 25 2010 - 22:00:03 PST
