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

[Benoit.Bleuze at sophia.inria.fr]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testSingleton.tar.gz
Type: application/x-gzip
Size: 655 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100526/37bf8ac0/attachment.bin>