Re: Re: segmentation fault when running ABF

From: Axel Kohlmeyer (
Date: Wed Aug 06 2008 - 11:31:42 CDT

On Wed, 6 Aug 2008, Vlad Cojocaru wrote:

VC> Hi Alex.

hi vald!

VC> Thanks a lot for the advices.. I was just writing the lines below when I got
VC> your email. The reason I tried with "-static" before was because that's what
VC> it appears in the default Linux-amd64-icc.arch file .....
VC> I succeeded to compile the cvs code of namd correctly (with the
VC> specifications mentioned in the emails below) and namd is able to run
VC> tclforces scripts (including abf) if linked to my own compilation of
VC> tcl8.4.19 with -DUSE_NON_CONST in CFLAGS.
VC> Also, the provided (on the namd website) precompiled tcl libs work as long
VC> as the "-static" option of icc is not used.

you may want to try using "-i-static" there. this will link the
icc runtime statically and thus allows to use the resulting executable
also on nodes that don't have the (matching) icc runtime installed
(as i wrote before. dynamic compiler runtimes proves that compiler
programmers don't _use_ applications compiled with their compilers
or they would realize what a nightmare this is).


VC> Best wishes
VC> vlad
VC> Axel Kohlmeyer wrote:
VC> > On Wed, 6 Aug 2008, Vlad Cojocaru wrote:
VC> >
VC> > VC> Hi Alex,
VC> >
VC> > hi vald!
VC> >
VC> > VC> Well .. I tried to compile using my own compilation of tcl8.5 because
VC> > VC> when
VC> > VC> trying with the precompiled libs (for linux-amd64) from the namd
VC> > VC> webpage
VC> > VC> (with the -static option added to the icc compiler) I get the error1
VC> > VC> (see
VC> >
VC> > why add -static??? linking completely statically is a "bad idea(tm)" on
VC> > any machine using glibc-2. furthermore, there is no gain from using intel
VC> > compiler to compile TCL. you are much better off using gcc/g++ for
VC> > everything that is not time critical as that will reduce
VC> > the dependencies on runtime libraries. particularly in libraries
VC> > that can be pretty nasty. on linux machines, you always have to depend
VC> > on the gcc runtime (why that one has to be dynamical i cannot comprehend,
VC> > but this is not the forum to discuss it).
VC> >
VC> > VC> below). Second, when I tried to compile tcl 8.3.5 I get a configure
VC> > VC> error
VC> >
VC> > use gcc to compile and drop the -static and it will work.
VC> > moreover, if your distribution provides a prepackaged tcl, why go through
VC> > the pains of building your own?
VC> >
VC> > VC> (error2 below). When I looked for the configure error on the tcl
VC> > VC> webpage I
VC> > VC> found the answer "tcl8.3.5" is an old verison .. if you upgrade, tcl
VC> > VC> should
VC> > VC> configure correctly". Then I thought OK .. I use the latest tcl and I
VC> > VC> should
VC> > VC> be fine .... So, that's the background of it ..
VC> >
VC> > yep. there is just one thing that one has to consider. using the
VC> > latest/greatest is usually OK with simple (small) applications as
VC> > those can be adapted quickly and with rather little effort, if needed.
VC> > but large complicated packages (like NAMD, VMD and many others) are
VC> > a different beast: first of all you want the application to excecute
VC> > absolutely correctly, always, then it has to be portable to many
VC> > platforms, many of which are "old", some even "legacy" and finally, there
VC> > are a frighteningly small number of people actually working on
VC> > maintaining and updating those codes. as a consequence progress is
VC> > usually very slow (you don't want to break anything that was working
VC> > and have to validate everything that gets added). it is especially scary
VC> > if one considers how many people actually put their trust into those
VC> > application and it is sometimes depressing to see how little respect
VC> > is being paid for all the hard work (and i mean respect as in actually
VC> > contributing to the effort, which is the best way to make sure that free
VC> > applications like NAMD do see more development in the future).
VC> >
VC> > VC> I also tried to add -DUSE_NON_CONST to my tcl8.5 compilation but still
VC> > VC> in
VC> > VC> vain ....
VC> > VC>
VC> > VC> Now, I guess I should try tcl 8.4 ..... as it seems that nobody has
VC> > VC> tried to
VC> > VC> build namd with tcl8.5 ...
VC> >
VC> > VC> For the record, I am trying on two different machines, both amd64
VC> > VC> architectures, on both intel 10.1.015 compilers. the namd code was
VC> > VC> downloaded from the cvs a week ago ...
VC> >
VC> > i would actually try building with gcc/g++ first.
VC> > most of the time you have a better chance to get a
VC> > working executable and _then_ you can try to see if
VC> > you get a better/faster binary from intel.
VC> >
VC> > the most important lesson in building package software is to do it in
VC> > stages, starting defensively and then
VC> > gradually move in stages to the full featured option
VC> > with all bells and whistles and optimizations.
VC> >
VC> > cheers,
VC> > axel.
VC> >
VC> >
VC> > VC> Best wishes
VC> > VC> vlad
VC> > VC>
VC> > VC> ---------------------------------------error2----------------------------------------------------------------------------------------------
VC> > VC> checking system version (for dynamic loading)... ./configure: line
VC> > VC> 6208:
VC> > VC> syntax error near unexpected token `)'
VC> > VC> ./configure: line 6208: ` OSF*)'
VC> > VC>
VC> >
VC> >

Axel Kohlmeyer
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
If you make something idiot-proof, the universe creates a better idiot.

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:48:08 CST