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

From: Mark Williamson <>
Date: Sat, 10 Jul 2004 18:54:56 +0100

Jiten wrote:

> PGC/x86-64 Linux/x86-64 5.1-6: compilation completed with warnings
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/ 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/ is a 32bit
  library and ld is not going to link a 64bit binary(ies) against it. I
suggest compiling 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, hence it puts the 64bit version of in the following

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

and checking that it is actually a 64bit object:

[root.e01 src]# file /usr/X11R6/lib64/
/usr/X11R6/lib64/ 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 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.e01 src]# pwd

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

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

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 =
      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....


Mark Williamson

The AMBER Mail Reflector
To post, send mail to
To unsubscribe, send "unsubscribe amber" to
Received on Sat Jul 10 2004 - 19:53:01 PDT
Custom Search