[MITgcm-support] G95 build issue: f2c name mangling

chris hill cnh at mit.edu
Mon Oct 9 20:16:32 EDT 2006


Mark/David,

   (1) changed some routine names and switched in Mark's form for 
TIMERS_GET_TIME. Things seem to still work for me, lets see how it goes.

  (2) Mark - we want to keep sys v. user v. wall numbers if poss.

Chris
David Ferreira wrote:
> Hi,
> 
> 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 
> "_user_time_"
> 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)
> and then
> (user_time, system_time) --> (usertime,systemtime)
> work ?
> 
> cheers,
> david
> 
> 
> chris hill wrote:
> 
>> Mark,
>>
>>  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.
>>
>> Thanks,
>>
>> Chris
>> 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
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> 




More information about the MITgcm-support mailing list