From: lc_at_chem.au.dk
Date: Fri Dec 31 2004 - 13:10:04 CST
Hi,
I have not tried to compile NAMD myself, but you must be aware, that there seems
to be general problems with the Portland Group Compiler on Fedora 3 core...
Leyla
Citat Gengbin Zheng <gzheng_at_ks.uiuc.edu>:
>
> Hi John,
>
> Welcome to the real Unix world! Imagining how many different
> architectures/venders/operating systems/communication hardwares and
> libraries/compilers you need to deal with in UNIX and its parallel
> flavors that NAMD faces (compared with windows applications).
> While we are trying to support as many environments as possible
> including windows, each porting requires additional effort and require
> followups due to vender libraries upgrades (clustermaric 3 and 4 for
> example is not backward compatiable due to change in bproc). Making
> binaries for all these environments is simply impossible and can be
> error prone when people trying to install redhat7 binaries on a redhat 9
> box for example. And we are simply lack of man power for doing such
> customer support and we don't have access to all machines with that many
> different configurations for doing compilations! ;-)
>
> Compiling Charm++/NAMD is difficult inherited from the complexity of
> parallel architectures, but it is the best because you can customize
> build for your needs according to the machine configuration. So far,
> NAMD runs on machines from PC Linux/windows, IA64, Opteron, Dec Alpha
> (our favorite for writing paper :) to IBM Bluegene/L whiling supporting
> 100M/Gigabit ethernet, myrinet, quadrics and infiniband. Most of times,
> compilation problems are due to compiler issues (sometimes even compiler
> bug) and vender library upgrades/compatibility problems.
>
> There are a lot of resource contributed by users also about how to
> compile NAMD such as NAMD wiki, and there are many successful stories
> installing NAMD presented in namd mailist which you can explore in the
> archive. Btw, we dont expect major problem of compiling NAMD on
> clustermatic 4 and opteron, you can always try to download latest
> Charm/NAMD from our cvs server since problem may have been solved after
> the previous release. Don't know clustermatic 5 yet since I don't know
> if they have major change in bproc library this time. And people are
> welcome to send bug report to NAMD developer group (namd_at_ks.uiuc.edu)
> or to this mailing list, as well as their complaints. Compiling
> Charm++/NAMD is difficult, but if you are really determined to do it and
> spend a little time exploring or asking around for help, you will make
> it. In worst cases, it happened that people are willing to give me
> account to their machines, in which case I will just go ahead and spend
> half hour compling Charm++/NAMD for them.
>
> I am not sure about the release plan in the near future (since in
> university, our main interest is in writing paper and/or thesis :-) ).
> However we are currently in the design/implementation phase of next
> generation of NAMD3. At the same time, NAMD2 is still actively
> maintained and getting improved along with Charm++.
>
> Gengbin
>
> John Saeger wrote:
>
> > Gosh, I'm surprise you're having a problem. (just kidding) To tell
> > you the truth, I've never been able to compile NAMD either. This
> > wouldn't bother me so much if NAMD binaries were kept up to date.
> > There have been no new binaries released since September 2003. So we
> > don't have Clustermatic 4 and we don't have Clustermatic 5. We don't
> > have Opterons either. But if we have a warehouse full of Dec Alphas
> > or something like that we're in fine shape.
> >
> > I know this wasn't very helpful, but I just wanted to let you know
> > that you are not alone, and if you figure it out, you should tell us
> > how you got NAMD to compile.
> >
> > John
> >
> >
> >
> > Ruxandra Dima wrote:
> >
> >> Hello,
> >>
> >> I have problems using the Namd-2.5 precompiled binaries on a Fedora
> >> Core 3
> >> workstation. My runs terminate randomly with the error
> >>
> >> Stack Traceback:
> >> [0] _ZN16ComputePatchPair6doWorkEv+0xa4 [0x8192b34]
> >> [1] _ZN11WorkDistrib12enqueueWorkBEP12LocalWorkMsg+0x19 [0x824b9cd]
> >> [2]
> >>
>
_ZN19CkIndex_WorkDistrib31_call_enqueueWorkB_LocalWorkMsgEPvP11WorkDistrib+0x11
>
> >>
> >> [0x824b9ad]
> >> [3] CkDeliverMessageFree+0x21 [0x827c1f9]
> >> [4] _Z15_processHandlerPvP11CkCoreState+0x393 [0x827d5e3]
> >> [5] CmiHandleMessage+0x1d [0x82b5e25]
> >> [6] _ZN9ScriptTcl7suspendEv+0xc [0x8228c68]
> >> [7] _ZN9ScriptTcl13runControllerEi+0x3f [0x8228c4f]
> >> [8] _ZN9ScriptTcl7Tcl_runEPvP10Tcl_InterpiPPc+0xf4 [0x82292cc]
> >> [9] TclInvokeStringCommand+0x6d [0x82c5145]
> >> [10] /home/dimar/NAMD/NAMD_2.5_Linux-i686/namd2 [0x82f946a]
> >> [11] Tcl_EvalEx+0x1cc [0x82f9b7c]
> >> [12] Tcl_EvalFile+0x157 [0x82f1ce3]
> >> [13] _ZN9ScriptTcl3runEPc+0x1a [0x8228b76]
> >> [14] main+0x1d2 [0x80ed052]
> >> [15] __libc_start_main+0xe3 [0x7b4e33]
> >> [16] sinh+0x65 [0x80eaed1]
> >>
> >> The same runs worked fine on Fedora Core 1 on the same workstation.
> >>
> >> I also tried unsuccessfully to compile Namd from source on Fedora Core 3
> >> (gcc-3.4.2). Charm compilation fails with the message:
> >>
> >> In file included from ccs-builtins.C:11:
> >> ckhashtable.h: In member function `OBJ CkHashtableT<KEY, OBJ>::get(const
> >> KEY&) const':
> >> ckhashtable.h:302: error: `len' undeclared (first use this function)
> >> ckhashtable.h:302: error: (Each undeclared identifier is reported only
> >> once for each function it appears in.)
> >> ckhashtable.h:304: error: there are no arguments to `entry' that
> >> depend on
> >> a template parameter, so a declaration of `entry' must be available
> >> ckhashtable.h:304: error: (if you use `-fpermissive', G++ will accept
> >> your
> >> code, but allowing the use of an undeclared name is deprecated)
> >> ckhashtable.h:306: error: `layout' undeclared (first use this function)
> >> ckhashtable.h:310: error: there are no arguments to `inc' that depend
> >> on a
> >> template parameter, so a declaration of `inc' must be available
> >> ckhashtable.h: In member function `OBJ& CkHashtableT<KEY,
> >> OBJ>::getRef(const KEY&)':
> >> ckhashtable.h:316: error: `len' undeclared (first use this function)
> >> ckhashtable.h:318: error: there are no arguments to `entry' that
> >> depend on
> >> a template parameter, so a declaration of `entry' must be available
> >> ckhashtable.h:320: error: `layout' undeclared (first use this function)
> >> ckhashtable.h:322: error: there are no arguments to `inc' that depend
> >> on a
> >> template parameter, so a declaration of `inc' must be available
> >> In file included from ccs-builtins.C:12:
> >> pup.h: In member function `CkReference<T>::operator T&()':
> >> pup.h:662: error: there are no arguments to `peek' that depend on a
> >> template parameter, so a declaration of `peek' must be available
> >> Fatal Error by charmc in directory
> >> /tmp/NAMD_2.5_Source/charm/net-linux/tmp
> >> Command g++ -Wno-deprecated -D__CHARMC__=1 -DCMK_OPTIMIZE=1 -O
> >> -I../bin/../include -c ccs-builtins.C -o ccs-builtins.o returned error
> >> code 1
> >> charmc exiting...
> >> make: *** [ccs-builtins.o] Error 1
> >>
> >> I would appreciate any suggestions.
> >>
> >> Thanks,
> >> Ruxandra
> >>
> >>
> >>
> >>
> >>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:39:05 CST