AMBER Archive (2004)

Subject: Re: AMBER: Problem amber8 compilation in Opteron(Linux) with PGI-workstation compiler

From: Mark Williamson (mark.williamson_at_imperial.ac.uk)
Date: Sat Jul 10 2004 - 12:54:56 CDT

Jiten wrote:

> PGC/x86-64 Linux/x86-64 5.1-6: compilation completed with warnings
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXt.so when
> searching for -lXt
> /usr/bin/ld: cannot find -lXt
> make[2]: *** [xaLeap] Error 2
> make[1]: *** [install] Error 2
> make: *** [serial] Error 2

I think this *may* be caused because /usr/X11R6/lib/libXt.so is a 32bit
  library and ld is not going to link a 64bit binary(ies) against it. I
suggest compiling libXt.so as a 64bit library.
Basically a library is a binary which provides a common and often used
functions to other programs. Instead of re-inventing the wheel,
programmers often create libraries that carry out common/repeated tasks
so that other programmers utilise those functions via linking instead of
rewriting their own implementation of them.

I'm using RHEL WS-3 AMD64 and it has both 32 and 64bit RPMs for
libXt.so, hence it puts the 64bit version of libXt.so in the following
location:

[root_at_e01 src]# rpm -ql XFree86-libs-4.3.0-62.EL | grep libXt.so
/usr/X11R6/lib64/libXt.so.6 (this is a symbolic link to the next file)
/usr/X11R6/lib64/libXt.so.6.0

and checking that it is actually a 64bit object:

[root_at_e01 src]# file /usr/X11R6/lib64/libXt.so.6.0
/usr/X11R6/lib64/libXt.so.6.0: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), stripped

I had similar issues, but not identical issues to you. My initial error
when I tried to compile was as follows:

pgcc -o xaLeap basics.o sysdepend.o stringExtra.o varArray.o
getline.o avl.o pdb_format.o pdb_read.o pdb_sprntf.o pdb_sscanf.o
pdb_write.o vector.o zMatrix.o sort.o bag.o hash.o dictionary.o
database.o nVector.o ring.o matrix.o fortran.o displayer.o assoc.o
atom.o byteArray.o collection.o container.o internal.o list.o loop.o
molecule.o oDouble.o oInteger.o oString.o objekt.o parmSet.o residue.o
unit.o unitio.o tripos.o graphUtil.o select.o amber.o build.o elements.o
library.o chirality.o minimizer.o model.o parmLib.o pdbFile.o tools.o
variables.o parser.o help.o helptext.o octree.o commands.o mathop.o
block.o restraint.o hybrid.o xTank.o xAction.o x3d.o xBasics.o
xaLeapc.o xaUnitEditor.o xaTable.o xaAtomTable.o XrawRegistr.o
xaCommand.o xaTools.o xaAtomParmTable.o xaBondParmTable.o
xaAngleParmTable.o xaParmEditor.o xaTorsionParmTable.o
xaImproperParmTable.o xaHBondParmTable.o ../Xraw/libXaw.a
../Wc/libWcLeap.a ../Xpm/libXpm.a ../Xmu/libXmu.a -L/usr/X11R6/lib -lXt
-lXext -lSM -lICE -lX11 -lm -lpthread
/usr/bin/ld: cannot find -lXt <----------------------
make[2]: *** [xaLeap] Error 2
make[2]: Leaving directory `/tmp/amber8.14/src/leap/src/leap'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/amber8.14/src/leap'
make: *** [serial] Error 2

Ok...so this suggested to me that pgcc could not find the Xt lib when
doing its final link stage. The "-L/usr/X11R6/lib" tells pgcc to look in
this dir for the libraries to link to. I need to tell it to look in
/usr/X11R6/lib64/ , the location of my 64 library. So... how do tell the
build process to this? Well, I searched all the source for a known; in
this cause it was "/usr/X11R6/lib";

[root_at_e01 src]# pwd
/tmp/amber8.14/src

[root_at_e01 src]# find ./ | xargs grep "/usr/X11R6/lib"
./leap/src/leap/Makefile:#/usr/X11R6/lib/libX11.a(XlcDL.o): In function
`try_both_dlsym':

In this case, I was lucky.. I did not match was I needed exactly, but it
was in the same file; ./leap/src/leap/Makefile
The important part as far as we're concerned is:

XALEAP_LIB = ../Xraw/libXaw.a ../Wc/libWcLeap.a ../Xpm/libXpm.a \
         ../Xmu/libXmu.a -L$(XHOME)/lib -lXt -lXext -lSM -lICE -lX11 -lm
-lpthread

My solution was a bit of a dirty hack; addition of a "
-L/usr/X11R6/lib64" to the leap Makefile.

XALEAP_LIB = ../Xraw/libXaw.a ../Wc/libWcLeap.a ../Xpm/libXpm.a \
         ../Xmu/libXmu.a -L$(XHOME)/lib -L/usr/X11R6/lib64 -lXt -lXext
-lSM -lICE -lX11 -lm -lpthread

Running make again from the root src, produced a complete build.

> cd dmp; ./Run.dmp
> ../Run.dmp: Program error

I also got this error. Looking further into the actual cause of the
"make test" failure; mdout.dmp:

Energy minimization:
      maxcyc = 5, ncyc = 10, ntmin = 1
      dx0 = 0.00010, drms = 0.00010

Polarizable options:
      indmeth = 1, maxiter = 20, irstdip = 0, scaldip =
       0
      diptau = 11.00000, dipmass = 0.33000
ASSERTion 'ier == 0' failed in extra_pts.f at line 223.

Looking at the reference file; ./src/sander/extra_pts.f around line 223

    maxa = max(max11,max12,max13,max14)
    allocate( s3(maxa), stat=ier )
    REQUIRE( ier == 0 )

It seems that this is somekind of program sanity check and that the
"make test" has failed at this point because integer "ier" is NOT
actually zero at this point. I think that this is the return value from
the allocate() function on the previous line. I'm also assuming "ier"
stands for "Integer Error"; i.e. in C speak, "a return value". When
functions work correctly, it is convention for a function to return a
value of 0 (zero).

Hence the issue probably lies with "allocate( s3(maxa), stat=ier )".

This is where I am now, my current knowledge of fortran/Amber8 internals
is insufficient to solve this one....

regards,

Mark Williamson
http://dumb.ch.ic.ac.uk/~mjw99/

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu