Dear Mark Williamson
Another problem I face after the compilation is that
setenv LEAPROOT /theo1/tmp/amber8/exe
setenv AMBERHOME /theo1/tmp/amber8
then
setenv DISPLAY IP(windows):0.0
then
xleap &
[1] 27875
csm43|/theo10/jiten:596> -I: Adding /theo1/tmp/amber8/dat/leap/prep to
search path.
-I: Adding /theo1/tmp/amber8/dat/leap/lib to search path.
-I: Adding /theo1/tmp/amber8/dat/leap/parm to search path.
-I: Adding /theo1/tmp/amber8/dat/leap/cmd to search path.
Segmentation fault (core dumped)
[1] Exit 139 xleap
----------------
Do you face this problem as well. I have X-manager. Any suggestions will be
highly thankful.
Regards,
Jiten
----- Original Message -----
From: "Mark Williamson" <mark.williamson.imperial.ac.uk>
To: <amber.scripps.edu>
Sent: Sunday, July 11, 2004 2:54 AM
Subject: Re: AMBER: Problem amber8 compilation in Opteron(Linux) with
PGI-workstation compiler
> 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
>
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun Jul 11 2004 - 06:53:00 PDT
