Hello,
See my comments below:
On Thu, May 20, 2010 at 8:44 PM, Kensuke Nakamura <kensuke-nm.is.naist.jp>wrote:
> Thank you very much for all kind supports!
>
> Dear Mengjuei,
> I updated the compiler to the latest version available, which was 11.1
> update 6 and the make completed!!
> Thanks a lot!
> However, as I tried to make test, I got another error,,,
>
> ----------------------------------------------------------------------------------------------------------
> [amber/amber10/test] kenske% make -f Makefile_at test
> ( cd nab; make test )
> =====================================================
> Running test to make dna duplex:
>
> /bin/sh: line 1: 1594 Segmentation fault ./duplex < duplex.in
> make[1]: *** [duplex_test] Error 139
> make: *** [test.nab] Error 2
>
> ----------------------------------------------------------------------------------------------------------
>
> Dear Dr. Case,
> I tried gcc first and did not work so I switched to icc..
> As I try to do it again, after './configure_at gcc' I get the following
> messages.
> ____________________________________________________________
> [:~/apps/amber10/src] kenske% make -f Makefile_at
> mkdir /Users/kenske/apps/amber10/bin /Users/kenske/apps/amber10/lib
> /Users/kenske/apps/amber10/include
> mkdir: /Users/kenske/apps/amber10/bin: File exists
> mkdir: /Users/kenske/apps/amber10/lib: File exists
> mkdir: /Users/kenske/apps/amber10/include: File exists
> make: [install] Error 1 (ignored)
> (cd ucpp-1.3 && make install )
> Makefile:35: warning: overriding commands for target `.c.o'
> ../config.h:99: warning: ignoring old commands for target `.c.o'
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE mem.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE nhash.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE cpp.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE lexer.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE assert.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE macro.c
> gcc -c -m32 -DBINTRAJ -DSTAND_ALONE eval.c
> gcc -o ucpp mem.o nhash.o cpp.o lexer.o assert.o macro.o eval.o
> ld: warning: in mem.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in nhash.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in cpp.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in lexer.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in assert.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in macro.o, file was built for i386 which is not the
> architecture being linked (x86_64)
> ld: warning: in eval.o, file was built for i386 which is not the
> architecture being linked (x86_64)
>
These are architecture issues arising from the new 64-bit support in snow
leopard. Look at the config.h and config_amber.h and remove all instances
of "-m32" or "-march=i686" or i386, or anything else that looks like it
could be implying a 32-bit architecture (since uname -m returns i386 for Mac
OS X 10.6 unless you boot into the 64-bit kernel).
Undefined symbols:
> "_main", referenced from:
> start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [ucpp] Error 1
> make: *** [install] Error 2
>
> --------------------------------------------------------------------------------------------------------
>
> Erik,
> Thank you very much for your extremely detailed instruction!
>
Amber10/AmberTools 1.2 procedure is quite a bit different from Amber11 and
AmberTools 1.4. However, AmberTools 1.4 is a free (open source) download
from ambermd.org, so I would recommend downloading that version of
AmberTools. The seg-fault you're seeing above is from AmberTools 1.2, and I
think that may have been fixed in the most recent version (1.4). Try
installing AmberTools 1.4 and seeing if that error goes away when you test
that installation.
Good luck!
Jason
> I have Amber10 and AmberTools1.2, so my procedure might be little
> different, right?
> I have Xtools3.2.2 but my gcc seems to be little old(4.2.1).
> I will try to update gcc and see if it works.
>
> kenske
>
> On 2010/05/20, at 17:26, Mengjuei Hsieh wrote:
>
> > On Wed, May 19, 2010 at 10:07 PM, Kensuke Nakamura
> > <kensuke-nm.is.naist.jp> wrote:
> >> amber.c(535) (col. 1): internal error: 0_1428
> >> compilation aborted for amber.c (code 4)
> >
> > Hi Kensuke,
> >
> > When you see an internal error from an Intel compiler, you can safely
> > bet that's a compiler problem. Judging from the forum post
> > http://software.intel.com/en-us/forums/showthread.php?t=68863, I think
> > you can try to upgrade to a later compiler version 11.1 update 3 and
> > see if that helps.
> > --
> > Mengjuei
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
> Kensuke Nakamura
> Nara Institute of Science and Technology
> Graduate School of Information Science
> 8916-5 Takayama, Ikoma, Nara 630-0101
> JAPAN
> TEL: +81-743-72-5257 (Fax:5258)
> E-mail: kensuke-nm.is.naist.jp
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu May 20 2010 - 18:00:04 PDT
