Hi David,
Thanks for getting back to me.
David A. Case wrote:
> On Mon, Sep 08, 2008, Ben Roberts wrote:
>> multisander.o(.text+0x3f): In function `MAIN__': : undefined
>> reference to `ncsu_sander_hooks_mp_on_multisander_exit_'
>> sander.o(.text+0x3d36): In function `sander_': : undefined
>> reference to `ncsu_sander_hooks_mp_on_sander_init_'
>> sander.o(.text+0x40be): In function `sander_': : undefined
>> reference to `ncsu_sander_hooks_mp_on_sander_exit_'
>> mdwrit.o(.text+0x26): In function `mdwrit_': : undefined reference
>> to `ncsu_sander_hooks_mp_on_mdwrit_' force.o(.text+0x255): In
>> function `force_.L': : undefined reference to
>> `ncsu_sander_hooks_mp_on_force_' force.o(.text+0x2e0d): In function
>> `force_.A': : undefined reference to
>> `ncsu_sander_hooks_mp_on_force_'
>>
>> This occurs when trying to combine Sander's many object files into
>> the sander executable.
>>
>> The compilation is known to work ok using the Fortran versions
>> 9.1.037 and 9.1.039. Is there any way around the problem in
>> 10.1.015 (the version of Intel 10 I'm trying to use)?
>
> Looks very odd to me. The 10.0.023 version of ifort (x86_64) works
> fine for me, as did many earlier versions.
Yes, I can get Amber to compile OK using 9.1.0xx as well, it seems. I
was switching to 10 to see if it would resolve the "debug version"
problem which was the subject of today's other email to the list. That
problem is present in 10.1 too, though, as it turns out.
>
>> In addition to running the configure_amber script with the
>> "ifort_x86_64" argument, I have made the following changes to the
>> config_amber.h file:
>>
>> - Replaced references to "gcc" with "icc" (using the Intel C
>> compiler 10.1.015 - the 64-bit version) - Replaced references to
>> "g++" with "icpc" - Replaced references to "cpp" with "fpp" and
>> took out the "-traditional" option
>
> Why are you making the above changes? The compiler probably won't
> hurt (it won't help either), but changing cpp to fpp could lead to
> funny behavior -- it would certainly be untested behavior, since
> amber developers would certainly be testing the stock install.
So Gustavo Seabra, a colleague of mine, also told me. He and I have been
testing the compilation using cpp since then, to no avail.
(As for why: I was following the suggestion of Viv Kendon
(
http://archive.ambermd.org/200708/0059.html),
having previously tried without her suggestions for fpp, etc.
Other things we've tried, also to no avail:
- Removing the -axWP compiler flag
- Compiling without binary trajectories (thus avoiding use of netcdf)
- Using the default (gcc/g++) compiler selection in the config files
- Using "ifort" in place of "ifort_x86_64"
I have to say, this continues to stump both of us!
Ben
--
Benjamin P. Roberts
Postdoctoral Research Associate
Quantum Theory Project
University of Florida
2301 New Physics Building #92
PO Box 118435
Gainesville FL 32611-8435
USA
Phone: +1 352 392 6712
Cell: +1 352 222 3677
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Wed Sep 10 2008 - 06:07:31 PDT
