Hi Ian:
Ian Hinder wrote:
Hi,
I have recently been getting the following linker error on some builds of the ET:
/home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e/lib/libthorn_CactusBindings.a(ScheduleGRHydro_InitData.c.o): In function `CCTKi_BindingsSchedule_GRHydro_InitData':
/home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e/bindings/Schedule/ScheduleGRHydro_InitData.c:185: undefined reference to `grhydro_cylindricalexplosionm_'
make[1]: *** [/home/ianhin/Cactus/EinsteinToolkitTests/exe/cactus_einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e] Error 1
make: *** [einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e] Error 2
It is reproducible, in the sense that I can run the build command again on the same configuration without cleaning it, and get the same error. But when a new configuration is built, the error goes away or changes. I first saw this a few days ago, and have never seen it before.
I haven't seen this error at all when I compile this routine. The only thing "special" about this routine with respect to others is that it
contains a fortran function definition in there. You said the error goes
away or changes in a new configuration. When it changes, does it happen
to routines in GRHydro that contains functions definitions like for
example, GRHydro_TVDReconstruct.F90 and GRHydro_Startup.F90? Maybe
encapsulating the function cyl_fr in GRHydro_CylindricalExplosionM.F90
helps, i.e. to insert a "contains" statement such that:
subroutine GRHydro_cylindricalexplosionM(...)
...
contains
function cyl_fr(...)
...
end function cyl_fr
end subroutine GRHydro_CylindricalExplosionM
In any case I am still puzzled about this issue, since there seem to be
no change in the flesh or FORTRAN thorn in the last few days that could
be responsible for this change in behavior. Was there any change/patch
in the compiler in the last few days in your system? Was there any change in your compiler option list?