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.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.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.e01 src]# pwd
/tmp/amber8.14/src
[root.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.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sat Jul 10 2004 - 19:53:01 PDT
