[MITgcm-support] G95 build issue: f2c name mangling
dfer at ocean.mit.edu
Mon Oct 9 12:16:48 EDT 2006
I run into exactly the same problem as Mark with g95 (including the
-fnosecond-unsderscore solving the MITgcm compilation but screwing
up the netcdf package)
So I tried the -ignoretime option of genmake2 and it didn't change anything:
there is still an error with a "_user_time__" in timers.o (.F) and a
in timer_stats.o (.c)
-ignoretime triggers a -DIGNORE_TIME flag which only appears
in timers.F. This flag seems to disable the functionality of the
time stuff, but not the definitions of the variables.
However adding a "ifndef IGNORE_TIME" around the definitions
seems to do the trick, but that would need to be checked in (and the time
utilities are lost)
As for Chris' suggestion, there are already a userTime and systemTime
variable defined in the timers.F subroutine. I don't really understand
what's going on in this subroutine, but could a brutal change such as
(userTime,systemTime) --> (toto,tutu)
(user_time, system_time) --> (usertime,systemtime)
chris hill wrote:
> Can you try changing
> system_time ==> systemtime
> user_time ==> usertime
> in timers.F and timer_stats.c.
> If I understood Ed correctly that should make the gnu linker happy.
> If it seems to work for you we can try and change it permanently - it
> shouldn't break anything else.
> Mark Hadfield wrote:
>> Thanks for your reply, Ed.
>> I agree that's irritating to have to go to so much trouble for a few
>> function calls that have no bearing on the results. Still, the time
>> info is moderately interesting.
>> I've discovered the reason for the inconsistency between g77 and g95
>> (the bit that was really bugging me). With the combination of
>> preprocessor symbols that applies on g77 and g95, the functions
>> system_time, user_time and timenow are declared but never called. G95
>> writes their names to the object file with the "U" (undefined) flag,
>> but g77 omits them. If I add a call to the system_time and user_time
>> functions, then g77 fails in the same way as g95. It's arguable which
>> is the more correct and user-friendly behaviour, but basically it's
>> an error in the code.
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
Ferreira David Tel : 617 253 7967
EAPS Room 54-1515,
Massachusetts Institute of Technology,
77 Massachusetts Avenue
Cambridge, MA, 02139
More information about the MITgcm-support