[Users] Linker errors

[Ian Hinder]

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.

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20120110/ff70a336/attachment.html