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.
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@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@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?
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@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@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?
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.
On 01/10/2012 07:14 AM, Ian Hinder wrote:
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:
- The previous suspicion concerning GRHydro was incorrect - the problem
seems to happen also with SymBase and CarpetSlab.
- 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
I saw something similar several months ago on my workstation. It turned out in the end the problem was a FPP flag (mistake) in my config where F90 files preprocessed files were redirected to a file ''penmp'' due to an erroneous config option FPP_OPTIMISE_OPTIONS= -DCARPET_OPTIMISE -DNDEBUG -openmp Perhaps looking at the verbose output from make will shed light onto what happened to your F90 files.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Bruno Coutinho Mundim -
Ian Hinder -
Yosef Zlochower