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> 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: <mailto:amber-developers.scripps.edu> 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
