[Users] Linker errors

[Bruno Coutinho Mundim]

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?


Cheers,
Bruno.

> The first time I saw it, the error was with one of the bindings files:
> 
>> 16039 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/lib/libthorn_CactusBindings.a(BindingsSchedule.c.o): In function `CCTKi_BindingsScheduleInitialise':
>> 16040 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/bindings/Schedule/BindingsSchedule.c:440: undefined reference to `CCTKi_BindingsSchedule_Hydro_InitExcision'
>> 16041 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/lib/libthorn_CactusBindings.a(BindingsParameterRecovery.c.o): In function `CCTKi_BindingsParameterRecoveryInitialise':
>> 16042 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/bindings/Schedule/BindingsParameterRecovery.c:689: undefined reference to `CCTKi_BindingsParameterRecovery_Hydro_InitExcision'
>> 16043 make[1]: *** [/home/ianhin/Cactus/EinsteinToolkitTests/exe/cactus_einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d] Error 1
>> 16044 make: *** [einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d] Error 2
> 
> The only thing in common is that the problem always seems to arise with GRHydro, but this might be a coincidence.
> 
> Looking back in the build log for the first case, I see:
> 
> 13013 COMPILING /home/ianhin/Cactus/EinsteinToolkitTests/arrangements/EinsteinInitialData/GRHydro_InitData/src/GRHydro_CylindricalExplosionM.F90
> 13014 : remark #5133: The input stream is empty
> 
> If this file were in fact empty, the linker error is what I would expect.  But the file does not seem to be empty, it does in fact contain the subroutine GRHydro_cylindricalexplosionM.  
> 
> The output files in the config directory seem to be OK:
> 
>> [ianhin at io1 EinsteinToolkitTests]$ wc configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.f90
>>  2637  7513 64109 configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.f90
>> [ianhin at io1 EinsteinToolkitTests]$ nm configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.F90.o 
>> 0000000000000000 N .debug_info_seg
>> 0000000000000018 r STRLITPACK_0
>> 0000000000000010 r STRLITPACK_1
>> 0000000000000008 r STRLITPACK_2
>> 0000000000000000 r STRLITPACK_3
>> 0000000000000000 r _2il0floatpacket.324
>> 0000000000000008 r _2il0floatpacket.325
>> 0000000000000010 r _2il0floatpacket.326
>> 0000000000000018 r _2il0floatpacket.327
>> 0000000000000020 r _2il0floatpacket.328
>> 0000000000000028 r _2il0floatpacket.329
>> 0000000000000030 r _2il0floatpacket.330
>> 0000000000000038 r _2il0floatpacket.331
>>                  U _intel_fast_memset
>> 000000000000007c C admbaserest_
>>                  U cctk_equals_
>> 0000000000002d60 T cyl_fr_
>>                  U exp
>> 0000000000000000 T grhydro_cylindricalexplosionm_
>> 0000000000000078 C grhydro_initdatapriv_
>> 0000000000000268 C grhydrorest_
>> 0000000000000058 C hydrobaserest_
>>                  U log
>>                  U prim2congenm_
>>                  U prim2conpolym_
> 
> Does anyone have an idea of why this might have started happening?
>