[Insight-users] Static compilation of itk in different dynamic libs

[Benoit.Bleuze at sophia.inria.fr]

Benoit.Bleuze at sophia.inria.fr wrote:
> Mathieu Malaterre wrote:
>> Hi Benoit,
>>
>>   [Congrats on the new job]
>>
>>   
> thank you
>> On Tue, May 25, 2010 at 4:50 PM,  <Benoit.Bleuze at sophia.inria.fr> wrote:
>>  
>>> Hi all,
>>>
>>> I am experiencing some problems with the static linking of itk and 
>>> the use
>>> of the included gdcm.
>>>
>>> Let's compile a static itk, then include it in 2 different 
>>> libraries, in my
>>> case they are then dynamically linked to a other third one in which 
>>> resides
>>> the executable. Call them libA and libB. Both use an 
>>> itkImageIOFactory at
>>> some point.
>>>
>>> They work fine, until the application closes, and the program tries to
>>> delete the gdcm::Global object internally used by the 
>>> itkGDCMImageIOFactory
>>> object which is created at instanciation time.
>>>
>>> The fact that the libraries A and B are not aware of one an other 
>>> results in
>>> the fact that gdcm::Global is created two times, but the constructor
>>> allocates the memory only once for the class variables in Global. 
>>> Obviously
>>> this crashes. This breaks the singleton pattern and I expected an 
>>> unexpected
>>> result. Is there a way to handle that situation in itk? For 
>>> instance, is
>>> there at least a way to not instanciate the gdcm factory along with the
>>> others? We don't use gdcm to deal with dicom images, and therefore 
>>> woudn't
>>> mind getting rid of this factory.
>>>
>>> Additional question: are there any other singleton classes that may 
>>> behave
>>> the same way and get me in trouble even further?
>>>     
>>
>> Your problem seems extremely easy to reproduce. Could you please
>> prepare a small cmakelists project that I can use to reproduce the
>> issue with ?
>> I did -shamelessly- copy the design of the gdcm singleton from vtk. I
>> believe the init / finalize of the class are working properly.
>>
>> By any chance are you using a MSVC compiler (I am thinking of a bug
>> that only occur in Release build).
>>
>> Thanks,
>>   
> Concerning the compiler, the problem didn't occur on MSVC, or at least 
> I didn't see it happening when the application  closed, I could try to 
> enable a console and check that for you, but you may rule out your MS 
> specific bug, since this happens definitely with GCC on linux platforms.
> From what I know of static variables imported in different shared 
> libraries from a single static library, you just can't predict the 
> behaviour.
>
> I attached that little toy example, you will see that if you use a 
> static itk a seg. fault occurs, and not when using a shared itk.
>
> By the way we are talking of the gdcm version included in itk, not the 
> stand alone version, let alone version 2. I have seen that gdcm v2 
> uses a reference counter when initializing gdcm::Global, which wasn't 
> present in the previous version. I will try with an external gdcm, but 
> I expect it to behave the same.
>
> Ben
Just a heads up on gdcm v2: no change compared with the version embedded 
in itk.

An other comment  on the svn version of gdcm 2.1, revision r66230 
compiles but breaks the inclusion to itk. The path to gdcmMSFF.so is not 
propagated any more. r6628 didn't have this problem.
'make' returns this error message:
/usr/bin/ld: cannot find -lgdcmMSFF

No idea on a work around my issue? I guess I will stick to a shared itk.

Ben.