Thanks for the message. However, as I posted a couple of days ago to
amber, the yacc issue arose when trying to compile amber9, which has
its own tools. And there was nothing else of amber around.
I had changed disks and needed a fully patched amber9 code to replace
certain *.f and recompile. When I compiled amber9 in the year 2007 on
previous disks (debian amd64 etch) all went on plainly and I was not
even aware of yacc. Now, with the fresh installation of debian amd64
lenny the yacc issue arose.
I have now copied from the old disks to the new disks amber 8, 9 and
10. To begin with, amber 9 passed all serial and parallel tests.
However, amber 9 is probably not fully patched (the bugfix.all file,
still in the directory, is 766114 bytes, while current bugfix.all is
1475863 bytes, although this does not fit the observation that current
amber9 bugfix.all is dated to 2006, before I compiled).
I am rather confused, whether to remove the installed "bison", or
leave if lenny needs it in order to compile amber9 and the issue has a
different origin than the parser
The original message to amber is below between ======= (it comprised
an attachment, which is also here)
=========================
Hi:
On a multisocket uma-type board with dual-opterons, following failure
of one disk of raid1, I have changed both with larger disks and
installed from scratch debian linux amd64 lenny raid1, intel compilers
10.1.015 and mkl lib.
As I want to install a modified version of amber9, I took from
previous working disk the ifort-gcc-mkl install of amber9, replaced
modified files in sander, recompiled, ending in failure.
In the remote hypothesis that previous installation was not fully
patched, I started from scratch, i.e.amber9 source. Patched with the
complete bugfix.all. To simplify, "chown -R francesco
/usr/local/amber9". First I tried to compile the standard
fully-patched version, ending in failure again:
$ ./configure ifort_x86_64
$ make clean 2>&1 | tee make.clean.out
$ make 2>&1 | tee make.out
make.clean.out reported what I guess are irrelevant errors. Last part reads:
rules.make:142: warning: ignoring old commands for target `/man3f90'
make[1]: *** No rule to make target `macros.make'. Stop.
make[1]: Leaving directory `/usr/local/amber9/src/netcdf/src'
make: [clean] Error 2 (ignored)
cd netcdf/lib && rm -f libnetcdf.a
/bin/sh: line 0: cd: netcdf/lib: No such file or directory
make: [clean] Error 1 (ignored)
cd netcdf/include && rm -f *.mod
/bin/sh: line 0: cd: netcdf/include: No such file or directory
make: [clean] Error 1 (ignored)
make.out ended in serious errors. Last part reads (attached please
find the whole out file):
build.c: In function ‘BuildInternalsForSimpleRings’:
build.c:2185: warning: passing argument 1 of
‘GraphUtilFindAllSmallestRingsAndRingGroups’ from incompatible pointer
type
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o elements.o elements.c
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o library.o library.c
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o chirality.o chirality.c
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o minimizer.o minimizer.c
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o model.o model.c
model.c: In function ‘zModelOrderAtoms’:
model.c:497: warning: passing argument 1 of ‘Sift’ from incompatible
pointer type
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o parmLib.o parmLib.c
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o pdbFile.o pdbFile.c
pdbFile.c: In function ‘zPdbBuildCoordinatesForContainer’:
pdbFile.c:1088: warning: passing argument 1 of ‘BuildFixInternals’
from incompatible pointer type
pdbFile.c: In function ‘zPdbAddAtom’:
pdbFile.c:1207: warning: passing argument 1 of
‘BuildInternalsForContainer’ from incompatible pointer type
pdbFile.c: In function ‘writeTER’:
pdbFile.c:1761: warning: initialization from incompatible pointer type
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o tools.o tools.c
tools.c: In function ‘iToolDistanceSearch’:
tools.c:1643: warning: passing argument 1 of ‘SortByDouble’ from
incompatible pointer type
tools.c:1643: warning: passing argument 4 of ‘SortByDouble’ from
incompatible pointer type
tools.c: In function ‘ToolOrientPrincipleAxisAlongCoordinateAxis’:
tools.c:1714: warning: passing argument 2 of ‘MathOpDiagonalize’ from
incompatible pointer type
gcc -c -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-m64 -O2 -o variables.o variables.c
yacc parser.y
make[2]: yacc: Command not found
make[2]: *** [parser.c] Error 127
make[2]: Leaving directory `/usr/local/amber9/src/leap/src/leap'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/local/amber9/src/leap'
make: *** [serial] Error 2
As far as I understand, the errors are related to X. A frequent "ifort
command line option -tp not supported" is probably irrelevant)
What I checked: startx provides the X server and a minimal window
(enough for xleap in my experience). Package "xorg-dev" and the
environment for compilation, package "build-essential" are installed
correctly.
gcc -v 4.3.2
make -v 3.81
=================
thanks
francesco pietra
On Thu, Apr 2, 2009 at 2:03 PM, David A. Case <case.biomaps.rutgers.edu> wrote:
> On Wed, Apr 01, 2009, Francesco Pietra wrote:
>>
>> yacc parser.y
>> make[2]: yacc: Command not found
>
> Here is one of many places where you would be well off upgrading to
> AmberTools for LEaP. It provides its own version of yacc, and has many
> other changes related to compatibility with more modern Linux
> distributions.
>
> AmberTools is free, and the LEaP code has not changed very much, so even
> if you have made changes to LEaP, it should be possible to port them to
> AmberTools.
>
> ...dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
Received on Fri Apr 03 2009 - 01:15:09 PDT
