I just happened to complete the installation of AmberTools 1.2 and Amber10 on Solaris10 X86.
The compilers which I happened to try were from SunStudio12 with so many names (suncc,sungcc, sunf89,sunf99, so &so) and the other pack was from GNU.
The GNU pack proved to be very valuable and to a certain extent requires less effort to compile the ambertools than the pack offered by Solaris.
* At first used GCC 3.4.3 , the compiler which comes up with solaris with g95 compiler which I happened to get from gnu website.
(Edited the code in configure_at file present in $AMBERHOME/src/ from gfortran/g77 to g95.Also changed the compiler flags settings fflags="-fno-automatic----"(original, works only g77/gfortran, I guess), fflags="-g"(generalized flag, not so very helpful), fflags="-o"(optimized, default when fflags is left blank, quite useful). It didn't work for me!Must have made some mistakes...)
The link has the article which I happnd 2 refer regarding fflags
http://www.gnu.org/software/libtool//manual/autoconf/Fortran-Compiler.html
*There was this _IMAGINARY_I (not defined)problem, which I mentioned previously in one of the posts, when I went in for make -f Makefile_at.
As David pointed out in his first reply to me
http://archive.ambermd.org/200809/0277.html , I can add _DUSE_AMBER_C9XCOMPLEX to the cflags variable present in $AMBERHOME/config.h . This is provided the complex.h is absent or it is a non standard one.
The system has /usr/include/complex.h, which Amber looks for through configure_at file(Thanks again Francis!).So,in this case the header file is a non standard one. And there is a patch that is required for complex header file present in solaris. It is mentioned in one of the articles
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313
So, the other way of solving this problem is define the imaginary I. There is an Imaginary_I that is been used in line no 1152 (under lnorm function) in nmode.c(present in $AMBERHOME/src/nab/nmode.c), which causes this error. It would have been multiplied with another complex variable. The way which I used to define this _Imaginary_I is complex volatile I=_Imaginary_I;//this should be present under the lnorm function, where the other complex variables are been used. though I guess volatile is not required in this case!(didn't try!!)
* Then after this, a new bug came in the form of undefined symbol fabs...symbol processing errors! This resulted due to the file bondtype.o file present in antechamber.I tried this after cleaning up using the make -f Makefile_at clean
*I happened to use ./configure_at -nox11 gcc, as there is no x11 been installed in solaris.
Again browsed for this error and in one of the articles it is been mentioned that it results due to the difference in the libraries between the c and the fortran.I tried with all combinations of c & fortran compilers which I downloaded from SUN website through SUN STUDIO 12 package.Thanks Altro for the suggestion but unfortunately it didn't work out for me!
*And in this article, the person says he was able to solve this problem(other software but!) by installing gcc 2.95(an older version!)
http://lists.beasts.org/pipermail/iftop-users/2004-March/000141.html
And so I looked for this compiler in www.sunfreeware.com/index10.html and got the set of g77, g90 and gcc 3.4.6. Easiest way to make! Added the new C compiler through addpkg -d <gcc-file-name> (Thanks Michael!) and prioritized the newly installed C compiler to the older one by setting PATH=/usr/local/bin:$PATH;export PATH (Thanks Roger!).
Reedited the config_at file to its original, as there is g77 and g90.
Configured and compiled after making the change to the nmode.c file, the program got installed successfully, saying I must compile sleap/xleap!
*The test program except for the simple lmod optimization ( -149!), ptraj_matrix(fluctuation, failed for all the following),1rrb_vac_mwcovarmat_evecs.dat.save, ala2.rtf.save, ala2_charmm.mol2.save and antechamber passed the tests!
I am not sure of the failed tests, whether they depend on the x11 libraries(need to check !). As I thought some bugfix might help atleast lmod optimization, I took the patch and used the command mentioned in it.
patch -p0 -r < bugfix.all
Then what I thought as a THE END came the new bug in the form of It looks like a new diff to me.
Solaris has a patch command, which is completely old!( Thats d reason!)
So downloaded the patch 2.5.4 from sunfreeware and patched the bugfix.all successfully, as I did with gcc but just to look puzzled on how to fix the problem of lmod!
I am sorry had it looked too long n verbose ! I tried my level best to make it interesting and also informative 2 a certain extent!
Looking forward for more suggestions n discussions (also will be back wid more questions!)! I thanked only a few people but what is implicit is there are more ppl (both online community and others), who helped me a lot to know in this incredulous, informative and in a way simple things made complicated journey!
----- Original Message -----
From: "David A. Case" <case.biomaps.rutgers.edu>
Date: Friday, September 26, 2008 11:17 am
Subject: Re: AMBER: compilation problem
To: amber.scripps.edu
> On Thu, Sep 25, 2008, Atro Tossavainen wrote:
> >
> > It doesn't even try to use the native FORTRAN compilers.
> I've explicitly
> > prevented the environment from seeing g77 and I don't have
> gfortran, so
> > I'm SOL, apparently. I'm not particularly impressed with
> this. I don't
> > think requiring the GNU compilers on these platforms is a good move.
>
> I don't understand why you have prevented the configuration
> script from
> seeing g77.
>
> The problem is not that we like GNU compilers, it is that the
> (modified)mopac6 code we use was written a long time ago, and
> uses constructs that
> are not portable to most modern fortran compilers.
> (Gfortran has some
> "g77-compatibility switches" that let you get enough g77-like behavior
> to work.)
>
> Our plan is to replace mopac with our code soon, and this will expand
> the range of fortran compiles that will work.
>
> Note also that it is only the mopac part of AmberTools that is
> disablednow if you don't have g77 or gfortran. Most of the
> uses of AmberTools
> are not tied to fortran compilers.
>
> ...dac
>
> [It *is* true, however, that Amber is almost exclusively
> developed on
> GNU/Linux systems, and we have only limited access to more traditional
> UNIX environments. This will surely lead to porting
> problems from time
> to time to non-Linux environments.]
> -----------------------------------------------------------------
> ------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo.scripps.edu
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Sun Sep 28 2008 - 05:09:28 PDT
