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

[David Ferreira]

Hi Chris,
Works fine for me.
Thanks
david

chris hill wrote:

> 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
>>
>>
>>
>>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support



-- 

Ferreira David               Tel : 617 253 7967 
EAPS Room 54-1515,
Massachusetts Institute of Technology,
77 Massachusetts Avenue
Cambridge, MA, 02139