[Users] Linker errors
yosef at astro.rit.edu
Tue Jan 10 07:31:56 CST 2012
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:
>>> I have recently been getting the following linker error on some
>>> builds of the ET:
>>>> In function `CCTKi_BindingsSchedule_GRHydro_InitData':
>>>> undefined reference to `grhydro_cylindricalexplosionm_'
>>>> make: ***
>>>> 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(...)
>> 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
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
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 at einsteintoolkit.org
Dr. Yosef Zlochower
Center for Computational Relativity and Gravitation
School of Mathematical Sciences
Rochester Institute of Technology
85 Lomb Memorial Drive
Rochester, NY 14623
Phone: +1 585-475-6103
yosef at astro.rit.edu
CONFIDENTIALITY NOTE: The information transmitted, including
attachments, is intended only for the person(s) or entity to which it
is addressed and may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon this information by persons or entities
other than the intended recipient is prohibited. If you received this
in error, please contact the sender and destroy any copies of this
More information about the Users