The deal on all these naming conventions is that they evolved from a base
name (ie., the functions got called one thing in sander originally, and
then it was discovered that something didn't work, so a define was added
to map around it). So if you want to dink with the base name, then you
have to check a dozen different things to be sure they work (sure, it's
simple, but people make simple mistakes, so until something is compiled
and linked and regression tested I don't believe it is correct, and that
goes for every platform I support). So we have something simple and
extensible that works. Now, the topic of elegance. Yes, a pile of macros
imported from cern may have certain generic flexibility, but I remember
looking at that stuff about 3 years ago, and it was a layer of complexity
that I felt no need to introduce whatsoever. I have to support something
like two or three calls to very simple c routines, and I have no strong
urge to add more c into the mix; it is a source of potential great grief
because consistent interfaces are not defined for all the old compilers
that we have to support (backward compatibility is the bear that looms
over a lot of attempts to move to more elegant solutions). Every time you
pick up something like this, somebody starts using a compiler that does
not fit the model. SO I quite intentionally don't pick up obfuscating
layers of stuff. I am really trying to get disengaged from this whole
autotools deal; it does not REALLY help me or the folks that use pmemd -
we have something that is pretty simple that works.
Thanks - Bob
----- Original Message -----
From: Xuebin Qiao <mailto:xbqiao.gmail.com>
To: amber-developers.scripps.edu
Sent: Thursday, October 27, 2005 5:11 PM
Subject: Re: amber-developers: question about ALTCC?
Hello, robert:
In addition, there may still bugs after Bugfix38 (if I do not guess
wrong), when you happen to use difference c function naming style (one has
no underscore and one has underscore) in the same file, say foo and foo_1.
On 10/28/05, Xuebin Qiao <xbqiao.gmail.com <mailto:xbqiao.gmail.com> >
wrote:
Hello, robert:
I guess if you chose a simple c function name without underscore (say
get_wall_time to getwalltime), you maybe do not have to define
DBL_C_UNDERSCORE.
I am sorry to murmur auto* over and over, and it may flame you. But for
this mix c and fortran programming issue, I think cfortran.h way or
name-demangling macro is more elegant technically.
On 10/28/05, Robert Duke < rduke.email.unc.edu
<mailto:rduke.email.unc.edu> > wrote:
Bugfix 38 defines DBL_C_UNDERSCORE which solves this problem for pmemd
using either g95 or pathscale compilers. As this autotools configuration
stuff gets more and more complicated and less and less transparent, my
initially lukewarm enthusiasm is waning even more. I had rather leave
pmemd out of the mix on this stuff. As it happens for amber 9 I now have
a very simple, transparent, and extensible configuration, dependency
generation and build process for this chunk of code which will probably
always by f95 with a little bit of c. As far as I am concerned, Xuebin
can stop worrying about pmemd (its the wrong freaking goal - we NEED
highly optimized extensible building for pmemd, not a process where anyone
can walk up, type configure, and something is built without a lot of
transparency).
Regards - Bob
----- Original Message -----
From: Xuebin Qiao <mailto:xbqiao.gmail.com>
To: amber-developers.scripps.edu
Sent: Thursday, October 27, 2005 4:04 PM
Subject: Re: amber-developers: question about ALTCC?
Hello dac:
In practice, I met a link problem when compile pmemd8. My g95 compiler
generate double underscore for c function (get_wall_time__), but the
source code happen to miss
the definition of get_wall_time__. So I have to patch the source code to
succeed compile.
CLINK_PLAIN and CLINK_CAPS are no succficient for handle this problem,
because lib/binpos.c happen to choose function name that only generate one
posfix underscore (openbinpos, readbinpos and etc). For function name that
has underscore (such as get_wall_time in pmemd_clib.c), compiler generate
double underscore, so it lead to link error.
Currently, there are two methods to handle mix c and fortran name mangling
as fas as I know.
i) use cfortran.h (www-zeus.desy.de/~burow/
<
http://www-zeus.desy.de/%7Eburow/> cfortran/) lib, this can make so
called transparent call between fortran and C. Interesting and without the
need of special configure treatment, but a little bit complex.
ii) define a macro to transform the name.
#define FC_FUNC(name, NAME) name##_ /*case for lowercase and one
underscore function name by fortran compiler.*/
in c code, we can define a function like this
#define FOO FC_FUNC(foo, FOO)
void FOO()
{}
in fortran code, simple call the lowercase name without postfix
underscore.
call foo
There are generally fix cases for name mangling, (foo, FOO, foo_ FOO_,
foo__, FOO__). The idea is to detect the real situation and generate
specific FC_FUNC macros (by -D flag, or defined in a header) at configure
time. Fortunately, autoconf can help us in most cases.
PS, could you help me to get contact with mike. I can not wait to see the
excited Amber9 and test my ideas. :-)
On 10/28/05, David A. Case <case.scripps.edu> wrote:
Same as amber8: define CLINK_PLAIN, CLINK_CAPS, etc. There is really
almost
zero C-fortran connections (walltime(), which you can get around, and
mmtsb(),
which is never really used....)
I don't know how to "autodetect" this for all possible pairs of fortran
and C
compliers. But in practice, it has not really been a problem.
...dac
Received on Wed Apr 05 2006 - 23:49:52 PDT
