On 7 Jan 2012, at 00:52, Bruno Coutinho Mundim wrote:
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?
According to our cluster administrator, nothing has changed on the cluster, and there has been no change to the option list. I am now convinced of the following things:
1. The previous suspicion concerning GRHydro was incorrect - the problem seems to happen also with SymBase and CarpetSlab.
2. The problems appear after completely irrelevant changes (e.g. to simfactory definitions for another machine - something that should have absolutely no connection to the build).
Given this, I now suspect some sort of problem on the machine I am running with, most likely related to the filesystem.