From julien.finet at kitware.com  Wed Feb  1 22:16:52 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 1 Feb 2012 17:16:52 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F226072.7060502@offis.de>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
Message-ID: <CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>

Hi Jorg,

Thanks for trying out and sorry for not getting back to you sooner.

I wrote a simpler project that reproduces the crash, can you try it on your
machine ?

If you look at the structure of the project, to crash I need 2 shared
libraries that include the same  diregist.h file.

Let me know how it goes. For information, I use the same DCMTK built by CTK:
$ ccmake -DDCMTK_DIR=~/Work/CTK/CTK-noPython/CMakeExternals/Install ../src

Thanks,
Julien.

On Fri, Jan 27, 2012 at 3:29 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi Julien,
>
>
>  To reproduce, simply run ctkDICOM (in Applications/ctkDICOM) in a linux
>> environment Ubuntu 11.10, gcc 4.6.1. For information, please note that I
>> can't reproduce the issue on my ubuntu 10.4.
>>
>
> as promised yesterday, I checked it on my private notebook with Ubuntu
> 11.10 (x86_64, gcc 4.6.1), but could not reproduce the crash.
>
>
> Regards,
> J?rg Riesmeier
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120201/caa99485/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ofConditionCrash.tar.gz
Type: application/x-gzip
Size: 3379 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120201/caa99485/attachment.bin>

From julien.finet at kitware.com  Fri Feb  3 13:41:55 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 3 Feb 2012 08:41:55 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F2BDF71.3050501@offis.de>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
Message-ID: <CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>

Great, thanks a lot !

Maybe we should upgrade the DCMTK version in CTK...

Thanks,
Julien.

On Fri, Feb 3, 2012 at 8:21 AM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi Julien,
>
>
>  I wrote a simpler project that reproduces the crash, can you try it on
>> your
>> machine ?
>>
>
> sure, I just did it and can confirm that the program crashes on this
> machine with the error message "pure virtual method called".
>
>
>  Let me know how it goes. For information, I use the same DCMTK built by
>> CTK:
>> $ ccmake -DDCMTK_DIR=~/Work/CTK/CTK-**noPython/CMakeExternals/**Install
>> ../src
>>
>
> Thank you for the hint, I used the same version of DCMTK and could
> reproduce the crash. When I used the current development version from our
> public git repository, it did not crash. Maybe, is has to do with our
> ongoing efforts regarding the support of shared libraries (see CHANGES
> file).
>
> Anyway, since the current concept of the OFCondition classes creates much
> trouble with both shared libraries and static objects, we are currently
> trying to rewrite the code.
>
>
> Regards,
> J?rg Riesmeier
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120203/19eeb510/attachment.htm>

From julien.finet at kitware.com  Fri Feb  3 16:40:13 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 3 Feb 2012 11:40:13 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
	<CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
Message-ID: <CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>

Hi Jorg,

I tried to compile CTK with the latest DCTMK and I still have the "pure
virtual method called" crash with DCMTK trunk compiled within CTK.
Minor changes to CTK must be done to be able to build CTK with DCMTK
trunk: (see https://github.com/finetjul/CTK/tree/dcmtk-trunk)
  (I then configure my ofConditionCrash project doing the following: ccmake
-DDCMTK_DIR:STRING=~/Work/CTK/CTK-Superbuild/CMakeExternals/Install ../src).
Can you suggest a work-around for the time being ?

However, if I manually build DCMTK, then there is no crash in my project
ofConditionCrash. I'm not sure what's different between DCMTK in CTK and a
stand alone DCMTK :-/

Anyway, when you guys rewrite the OfCondition code, can you please try to
build DCMTK in CTK and test the ofConditionCrash project (you might want to
make it a unit test within DCMTK) ?

Thanks a lot for your help,
Julien.
p.s. see bellow a DCMTK trunk build error (ubuntu 11.10, 64bits, cmake
2.8.5) with a suggested fix.

HEAD is now at b99bb83... Don't call MSVC++ with -fvisibility=hidden.
[ 60%] [ 60%] No update step for 'DCMTK'
No patch step for 'DCMTK'
[ 60%] Performing configure step for 'DCMTK'
loading initial cache file
/home/julien/Work/Slicer/Slicer4/Slicer4-Debug/CTK-build/DCMTK-cmake/tmp/DCMTK-cache.cmake
CMake Error at CMake/FindICONV.cmake:20 (FIND_PACKAGE_HANDLE_STANDARD_ARGS):
  Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS".
Call Stack (most recent call first):
  CMake/3rdparty.cmake:229 (FIND_PACKAGE)
  CMakeLists.txt:260 (INCLUDE)

-- Configuring incomplete, errors occurred!
make[5]: *** [DCMTK-cmake/src/DCMTK-stamp/DCMTK-configure] Error 1
make[4]: *** [CMakeFiles/DCMTK.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-build] Error 2
make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
make: *** [all] Error 2

Can be fixed by adding: include(FindPackageHandleStandardArgs) in
CMake/FindICONV.cmake

On Fri, Feb 3, 2012 at 8:41 AM, Julien Finet <julien.finet at kitware.com>wrote:

> Great, thanks a lot !
>
> Maybe we should upgrade the DCMTK version in CTK...
>
> Thanks,
> Julien.
>
> On Fri, Feb 3, 2012 at 8:21 AM, OFFIS DICOM Team <dicom at offis.de> wrote:
>
>> Hi Julien,
>>
>>
>>  I wrote a simpler project that reproduces the crash, can you try it on
>>> your
>>> machine ?
>>>
>>
>> sure, I just did it and can confirm that the program crashes on this
>> machine with the error message "pure virtual method called".
>>
>>
>>  Let me know how it goes. For information, I use the same DCMTK built by
>>> CTK:
>>> $ ccmake -DDCMTK_DIR=~/Work/CTK/CTK-**noPython/CMakeExternals/**Install
>>> ../src
>>>
>>
>> Thank you for the hint, I used the same version of DCMTK and could
>> reproduce the crash. When I used the current development version from our
>> public git repository, it did not crash. Maybe, is has to do with our
>> ongoing efforts regarding the support of shared libraries (see CHANGES
>> file).
>>
>> Anyway, since the current concept of the OFCondition classes creates much
>> trouble with both shared libraries and static objects, we are currently
>> trying to rewrite the code.
>>
>>
>> Regards,
>> J?rg Riesmeier
>> --
>> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120203/5ca5dac8/attachment.htm>

From m.nolden at dkfz-heidelberg.de  Wed Feb 15 14:13:08 2012
From: m.nolden at dkfz-heidelberg.de (Marco Nolden)
Date: Wed, 15 Feb 2012 15:13:08 +0100
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
	<CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
	<CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>
Message-ID: <4F3BBD74.6030503@dkfz.de>

Hi J?rg and Julien,

I'm also affected by the problem now on Fedora 16. Is there any 
workaround? I can't start our application at all. @Julien: did you 
notice which change in CTK introduced the problem?

Best
Marco


On 02/03/2012 05:40 PM, Julien Finet wrote:
> Hi Jorg,
>
> I tried to compile CTK with the latest DCTMK and I still have the "pure
> virtual method called" crash with DCMTK trunk compiled within CTK.
> Minor changes to CTK must be done to be able to build CTK with DCMTK
> trunk: (see https://github.com/finetjul/CTK/tree/dcmtk-trunk)
>    (I then configure my ofConditionCrash project doing the following:
> ccmake
> -DDCMTK_DIR:STRING=~/Work/CTK/CTK-Superbuild/CMakeExternals/Install ../src).
> Can you suggest a work-around for the time being ?
>
> However, if I manually build DCMTK, then there is no crash in my project
> ofConditionCrash. I'm not sure what's different between DCMTK in CTK and
> a stand alone DCMTK :-/
>
> Anyway, when you guys rewrite the OfCondition code, can you please try
> to build DCMTK in CTK and test the ofConditionCrash project (you might
> want to make it a unit test within DCMTK) ?
>
> Thanks a lot for your help,
> Julien.
> p.s. see bellow a DCMTK trunk build error (ubuntu 11.10, 64bits, cmake
> 2.8.5) with a suggested fix.
>
> HEAD is now at b99bb83... Don't call MSVC++ with -fvisibility=hidden.
> [ 60%] [ 60%] No update step for 'DCMTK'
> No patch step for 'DCMTK'
> [ 60%] Performing configure step for 'DCMTK'
> loading initial cache file
> /home/julien/Work/Slicer/Slicer4/Slicer4-Debug/CTK-build/DCMTK-cmake/tmp/DCMTK-cache.cmake
> CMake Error at CMake/FindICONV.cmake:20 (FIND_PACKAGE_HANDLE_STANDARD_ARGS):
>    Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS".
> Call Stack (most recent call first):
>    CMake/3rdparty.cmake:229 (FIND_PACKAGE)
>    CMakeLists.txt:260 (INCLUDE)
>
> -- Configuring incomplete, errors occurred!
> make[5]: *** [DCMTK-cmake/src/DCMTK-stamp/DCMTK-configure] Error 1
> make[4]: *** [CMakeFiles/DCMTK.dir/all] Error 2
> make[3]: *** [all] Error 2
> make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-build] Error 2
> make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
> make: *** [all] Error 2
>
> Can be fixed by adding: include(FindPackageHandleStandardArgs) in
> CMake/FindICONV.cmake
>
> On Fri, Feb 3, 2012 at 8:41 AM, Julien Finet <julien.finet at kitware.com
> <mailto:julien.finet at kitware.com>> wrote:
>
>     Great, thanks a lot !
>
>     Maybe we should upgrade the DCMTK version in CTK...
>
>     Thanks,
>     Julien.
>
>     On Fri, Feb 3, 2012 at 8:21 AM, OFFIS DICOM Team <dicom at offis.de
>     <mailto:dicom at offis.de>> wrote:
>
>         Hi Julien,
>
>
>             I wrote a simpler project that reproduces the crash, can you
>             try it on your
>             machine ?
>
>
>         sure, I just did it and can confirm that the program crashes on
>         this machine with the error message "pure virtual method called".
>
>
>             Let me know how it goes. For information, I use the same
>             DCMTK built by CTK:
>             $ ccmake
>             -DDCMTK_DIR=~/Work/CTK/CTK-__noPython/CMakeExternals/__Install
>             ../src
>
>
>         Thank you for the hint, I used the same version of DCMTK and
>         could reproduce the crash. When I used the current development
>         version from our public git repository, it did not crash. Maybe,
>         is has to do with our ongoing efforts regarding the support of
>         shared libraries (see CHANGES file).
>
>         Anyway, since the current concept of the OFCondition classes
>         creates much trouble with both shared libraries and static
>         objects, we are currently trying to rewrite the code.
>
>
>         Regards,
>         J?rg Riesmeier
>         --
>         OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>         E-Mail: dicom at offis.de <mailto:dicom at offis.de>, URL:
>         http://dicom.offis.de
>
>
>


-- 
----------------------------------------------------------------------
Dipl.-Inform. Med. Marco Nolden
Deutsches Krebsforschungszentrum       (German Cancer Research Center)
Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de


From m.nolden at dkfz-heidelberg.de  Wed Feb 15 14:06:19 2012
From: m.nolden at dkfz-heidelberg.de (Marco Nolden)
Date: Wed, 15 Feb 2012 15:06:19 +0100
Subject: [Ctk-developers] sparkit and ctk
In-Reply-To: <CA+OFd4wbxhB3BZbToy77mxyJz9JkkM=UJa6bcywngFJ0eqekTw@mail.gmail.com>
References: <CA+OFd4wbxhB3BZbToy77mxyJz9JkkM=UJa6bcywngFJ0eqekTw@mail.gmail.com>
Message-ID: <4F3BBBDB.9080308@dkfz.de>

Hi Steve,

that is good news, and a nice summary of existing interfaces. Welcome to 
the SparKit team!

We are currently in the process of integrating the CTK DICOM classes in 
the MITK application. Up to now we made only minimal changes to the CTK 
import and browsing code but we also got a few ideas for improvements 
and refactorings. Our student is right in the middle of finishing the 
integration work and I guess there will be presentable results in 
something like 4 weeks. But of course we could have a phone call or 
hangout before.

Best,
Marco


On 01/26/2012 11:26 PM, Steve Pieper wrote:
> Hi CTKers -
>
> I wanted to introduce everyone to some of our collaborators who have
> recently joined the CTK developers mailing list. Andras Lasso, Csaba
> Pinter, Kevin Wang, and Elvis Chen are part of the SparKit effort by the
> Ontario government to improve radiation therapy research.  SparKit will
> use CTK via Slicer  (More info at links [1], [2] and [3] below).  As
> part of this they and are going to start asking some questions and
> making some contribution/suggestions to enhance the ctkDICOM code base.
> In particular, we've been discussing how the DICOM browser (e.g.
> ctkDICOMModel and ctkDICOMAppWidget) could be improved to look and act
> more like a clinical system -- at link [4] below you'll see notes from
> recent discussions along with screenshots from several clinical
> interfaces for reference.
>
> One of the things we'd like to do is start an email discussion of a few
> CTK-related issues and then follow up with a phone call (or better, a
> google hangout session) to get input from the CTK community.  We'll for
> sure want to coordinate with Micheal, Julien, and Marco, but everyone
> with an interest is welcome to participate.
>
> Best,
> Steve
>
> [1] http://www.na-mic.org/Wiki/index.php/Collaboration:SparKit/OCAIRO
>
> [2] https://www.assembla.com/wiki/show/sparkit/SlicerRt
>
> [3] http://www.na-mic.org/Wiki/index.php/2012_Winter_Project_Week:RTTools
>
> [4]
> https://www.assembla.com/spaces/sparkit/wiki/20120125_Slicer_DICOM_browser_meeting
>


-- 
----------------------------------------------------------------------
Dipl.-Inform. Med. Marco Nolden
Deutsches Krebsforschungszentrum       (German Cancer Research Center)
Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de


From julien.finet at kitware.com  Wed Feb 15 14:18:51 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 15 Feb 2012 09:18:51 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F3BBD74.6030503@dkfz.de>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
	<CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
	<CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>
	<4F3BBD74.6030503@dkfz.de>
Message-ID: <CAKoWPPEdCHWpEJ7R0cND6Jq5G0uhnUKRcgLRbai-AdMRiPLFsw@mail.gmail.com>

Hi Marco,

Sorry, I don't know since when the problem appeared as we "recently" (few
months) added the DICOM support in Slicer and the crash is somewhat tricky
to reproduce and not on all machines (I had to install a VM to investigate
the issue).

Julien.

On Wed, Feb 15, 2012 at 9:13 AM, Marco Nolden
<m.nolden at dkfz-heidelberg.de>wrote:

> Hi J?rg and Julien,
>
> I'm also affected by the problem now on Fedora 16. Is there any
> workaround? I can't start our application at all. @Julien: did you notice
> which change in CTK introduced the problem?
>
> Best
> Marco
>
>
>
> On 02/03/2012 05:40 PM, Julien Finet wrote:
>
>> Hi Jorg,
>>
>> I tried to compile CTK with the latest DCTMK and I still have the "pure
>> virtual method called" crash with DCMTK trunk compiled within CTK.
>> Minor changes to CTK must be done to be able to build CTK with DCMTK
>> trunk: (see https://github.com/finetjul/**CTK/tree/dcmtk-trunk<https://github.com/finetjul/CTK/tree/dcmtk-trunk>
>> )
>>   (I then configure my ofConditionCrash project doing the following:
>> ccmake
>> -DDCMTK_DIR:STRING=~/Work/CTK/**CTK-Superbuild/CMakeExternals/**Install
>> ../src).
>> Can you suggest a work-around for the time being ?
>>
>> However, if I manually build DCMTK, then there is no crash in my project
>> ofConditionCrash. I'm not sure what's different between DCMTK in CTK and
>> a stand alone DCMTK :-/
>>
>> Anyway, when you guys rewrite the OfCondition code, can you please try
>> to build DCMTK in CTK and test the ofConditionCrash project (you might
>> want to make it a unit test within DCMTK) ?
>>
>> Thanks a lot for your help,
>> Julien.
>> p.s. see bellow a DCMTK trunk build error (ubuntu 11.10, 64bits, cmake
>> 2.8.5) with a suggested fix.
>>
>> HEAD is now at b99bb83... Don't call MSVC++ with -fvisibility=hidden.
>> [ 60%] [ 60%] No update step for 'DCMTK'
>> No patch step for 'DCMTK'
>> [ 60%] Performing configure step for 'DCMTK'
>> loading initial cache file
>> /home/julien/Work/Slicer/**Slicer4/Slicer4-Debug/CTK-**
>> build/DCMTK-cmake/tmp/DCMTK-**cache.cmake
>> CMake Error at CMake/FindICONV.cmake:20 (FIND_PACKAGE_HANDLE_STANDARD_**
>> ARGS):
>>   Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_**ARGS".
>> Call Stack (most recent call first):
>>   CMake/3rdparty.cmake:229 (FIND_PACKAGE)
>>   CMakeLists.txt:260 (INCLUDE)
>>
>> -- Configuring incomplete, errors occurred!
>> make[5]: *** [DCMTK-cmake/src/DCMTK-stamp/**DCMTK-configure] Error 1
>> make[4]: *** [CMakeFiles/DCMTK.dir/all] Error 2
>> make[3]: *** [all] Error 2
>> make[2]: *** [CTK-prefix/src/CTK-stamp/CTK-**build] Error 2
>> make[1]: *** [CMakeFiles/CTK.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Can be fixed by adding: include(**FindPackageHandleStandardArgs) in
>> CMake/FindICONV.cmake
>>
>> On Fri, Feb 3, 2012 at 8:41 AM, Julien Finet <julien.finet at kitware.com
>> <mailto:julien.finet at kitware.**com <julien.finet at kitware.com>>> wrote:
>>
>>    Great, thanks a lot !
>>
>>    Maybe we should upgrade the DCMTK version in CTK...
>>
>>    Thanks,
>>    Julien.
>>
>>    On Fri, Feb 3, 2012 at 8:21 AM, OFFIS DICOM Team <dicom at offis.de
>>    <mailto:dicom at offis.de>> wrote:
>>
>>        Hi Julien,
>>
>>
>>            I wrote a simpler project that reproduces the crash, can you
>>            try it on your
>>            machine ?
>>
>>
>>        sure, I just did it and can confirm that the program crashes on
>>        this machine with the error message "pure virtual method called".
>>
>>
>>            Let me know how it goes. For information, I use the same
>>            DCMTK built by CTK:
>>            $ ccmake
>>            -DDCMTK_DIR=~/Work/CTK/CTK-__**noPython/CMakeExternals/__**
>> Install
>>
>>            ../src
>>
>>
>>        Thank you for the hint, I used the same version of DCMTK and
>>        could reproduce the crash. When I used the current development
>>        version from our public git repository, it did not crash. Maybe,
>>        is has to do with our ongoing efforts regarding the support of
>>        shared libraries (see CHANGES file).
>>
>>        Anyway, since the current concept of the OFCondition classes
>>        creates much trouble with both shared libraries and static
>>        objects, we are currently trying to rewrite the code.
>>
>>
>>        Regards,
>>        J?rg Riesmeier
>>        --
>>        OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
>>        E-Mail: dicom at offis.de <mailto:dicom at offis.de>, URL:
>>        http://dicom.offis.de
>>
>>
>>
>>
>
> --
> ------------------------------**------------------------------**----------
> Dipl.-Inform. Med. Marco Nolden
> Deutsches Krebsforschungszentrum       (German Cancer Research Center)
> Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
> Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
> D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120215/2b3b826a/attachment.htm>

From julien.finet at kitware.com  Wed Feb 15 15:54:54 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 15 Feb 2012 10:54:54 -0500
Subject: [Ctk-developers] Team page
Message-ID: <CAKoWPPHyGs7tGNBhFm=4EauVb+kitk80o+mrg1pbk-7EUWYJNg@mail.gmail.com>

Hi CTKers,

I redesigned the "team" page: http://www.commontk.org/index.php/The_Team
I especially added the "grant/funding/sponsors" section to acknowledge our
funding organizations.

Please add/edit/remove missing/wrong information...
Make sure I used the right logos for your institution/project.

Feel free to reorganize the "people" section.

Thanks,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120215/c5132b6c/attachment.htm>

From m.nolden at dkfz-heidelberg.de  Wed Feb 15 16:04:52 2012
From: m.nolden at dkfz-heidelberg.de (Marco Nolden)
Date: Wed, 15 Feb 2012 17:04:52 +0100
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F3BCCC9.70709@offis.de>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
	<CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
	<CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>
	<4F3BBD74.6030503@dkfz.de> <4F3BCCC9.70709@offis.de>
Message-ID: <4F3BD7A4.8040506@dkfz-heidelberg.de>

Hi J?rg,

thanks. I just changed the DCMTK build type to SHARED inside of CTK and 
it worked as well (plain 3.6 release). Unfortunately I can't remember 
why we switched to static. For windows? jc?

Since updating everything to some intermediate version of DCMTK has a 
lot of implications for us we would prefer to use this solution if 
possible. Let's wait if anyone can remember why a shared DCMTK was a bad 
idea ...

Best,
Marco


On 02/15/2012 04:18 PM, OFFIS DICOM Team wrote:
> Hi Marco,
>
>> I'm also affected by the problem now on Fedora 16. Is there any
>> workaround? I can't start our application at all.
>
> good question. We've just committed a major rewrite of the OFCondition class
> that should solve this (and all related) issues:
>
>
> http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=19ec80fae2dda21af1d3c3eb9be279a64c70e21e
>
> Unfortunately, I could not test yet whether it really works with Julien's
> test program. This is something I have to do this evening with my private
> notebook (Ubuntu 11.10), a system on which I could reproduce the crash with
> the old implementation.
>
> Regards,
> J?rg Riesmeier


-- 
----------------------------------------------------------------------
Dipl.-Inform. Med. Marco Nolden
Deutsches Krebsforschungszentrum       (German Cancer Research Center)
Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de


From benoit.bleuze at inria.fr  Wed Feb 15 16:07:31 2012
From: benoit.bleuze at inria.fr (Benoit Bleuze)
Date: Wed, 15 Feb 2012 17:07:31 +0100 (CET)
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F3BD7A4.8040506@dkfz-heidelberg.de>
Message-ID: <1467004407.834942.1329322051504.JavaMail.root@zmbs4.inria.fr>

Hi Marco,
DCMTK definitely does not compile as a shared lib on Windows :-(

Ben.

----- Original Message -----
> Hi J?rg,
> 
> thanks. I just changed the DCMTK build type to SHARED inside of CTK
> and
> it worked as well (plain 3.6 release). Unfortunately I can't remember
> why we switched to static. For windows? jc?
> 
> Since updating everything to some intermediate version of DCMTK has a
> lot of implications for us we would prefer to use this solution if
> possible. Let's wait if anyone can remember why a shared DCMTK was a
> bad
> idea ...
> 
> Best,
> Marco
> 
> 
> On 02/15/2012 04:18 PM, OFFIS DICOM Team wrote:
> > Hi Marco,
> >
> >> I'm also affected by the problem now on Fedora 16. Is there any
> >> workaround? I can't start our application at all.
> >
> > good question. We've just committed a major rewrite of the
> > OFCondition class
> > that should solve this (and all related) issues:
> >
> >
> > http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=19ec80fae2dda21af1d3c3eb9be279a64c70e21e
> >
> > Unfortunately, I could not test yet whether it really works with
> > Julien's
> > test program. This is something I have to do this evening with my
> > private
> > notebook (Ubuntu 11.10), a system on which I could reproduce the
> > crash with
> > the old implementation.
> >
> > Regards,
> > J?rg Riesmeier
> 
> 
> --
> ----------------------------------------------------------------------
> Dipl.-Inform. Med. Marco Nolden
> Deutsches Krebsforschungszentrum (German Cancer Research Center)
> Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325
> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345
> D-69120 Heidelberg eMail: M.Nolden at dkfz.de
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers


From jchris.fillionr at kitware.com  Wed Feb 15 16:22:04 2012
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Wed, 15 Feb 2012 11:22:04 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <4F3BD7A4.8040506@dkfz-heidelberg.de>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F226072.7060502@offis.de>
	<CAKoWPPFysN5T463CeD+9B0AAs_XQm5b1N5vmtu24SDo8-iHQFQ@mail.gmail.com>
	<4F2BDF71.3050501@offis.de>
	<CAKoWPPFtUpeO1Ghw2XqKFa9N40GKw0D42WUb3iOe5ZY_KiFqsw@mail.gmail.com>
	<CAKoWPPGAOPGomeyO+weiPZ9NhtgoANyELQkC7x+f2faeFvcKcQ@mail.gmail.com>
	<4F3BBD74.6030503@dkfz.de> <4F3BCCC9.70709@offis.de>
	<4F3BD7A4.8040506@dkfz-heidelberg.de>
Message-ID: <CANLz8R6bKr9OQYKJ8HdcXZsObV0Udr7y1QmCVHMt1wa=xwh7Xw@mail.gmail.com>

Hi Marco,

I don't remember any particular issue with building DCMTK as shared
library. That said, we should make sure it compiles as expected on windows
and also work as expected when installed / packaged.

The motivation with having such external dependencies build statically
makes the install of CTK tree easier. Indeed, doing something like [1] is
enough to install all runtime libraries provided directly by CTK.

We could also think about a better way to specify which component
associated with external project should be installed when installing CTK.
Currently we a using something like [2] to install the DCMTK application.

Building statically also prevents possible issues when using DCMTK apps
directly from the command line. There is no need for a launcher or no need
to enforce that the DCMTK shared libraries are in a specific location.

Thanks
Jc

[1]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallCMakeProjects.cmake#L47
[2]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallDCMTKApps.cmake
On Wed, Feb 15, 2012 at 11:04 AM, Marco Nolden
<m.nolden at dkfz-heidelberg.de>wrote:

> Hi J?rg,
>
> thanks. I just changed the DCMTK build type to SHARED inside of CTK and it
> worked as well (plain 3.6 release). Unfortunately I can't remember why we
> switched to static. For windows? jc?
>
> Since updating everything to some intermediate version of DCMTK has a lot
> of implications for us we would prefer to use this solution if possible.
> Let's wait if anyone can remember why a shared DCMTK was a bad idea ...
>
> Best,
> Marco
>
>
> On 02/15/2012 04:18 PM, OFFIS DICOM Team wrote:
>
>> Hi Marco,
>>
>>
>>  I'm also affected by the problem now on Fedora 16. Is there any
>>> workaround? I can't start our application at all.
>>>
>>
>> good question. We've just committed a major rewrite of the OFCondition
>> class
>> that should solve this (and all related) issues:
>>
>>
>> http://git.dcmtk.org/web?p=**dcmtk.git;a=commit;h=**
>> 19ec80fae2dda21af1d3c3eb9be279**a64c70e21e<http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=19ec80fae2dda21af1d3c3eb9be279a64c70e21e>
>>
>> Unfortunately, I could not test yet whether it really works with Julien's
>> test program. This is something I have to do this evening with my private
>> notebook (Ubuntu 11.10), a system on which I could reproduce the crash
>> with
>> the old implementation.
>>
>> Regards,
>> J?rg Riesmeier
>>
>
>
> --
> ------------------------------**------------------------------**----------
> Dipl.-Inform. Med. Marco Nolden
> Deutsches Krebsforschungszentrum       (German Cancer Research Center)
> Div. Medical & Biological Informatics          Tel: (+49) 6221-42 2325
> Im Neuenheimer Feld 280                        Fax: (+49) 6221-42 2345
> D-69120 Heidelberg                             eMail: M.Nolden at dkfz.de
> ______________________________**_________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-**bin/mailman/listinfo/ctk-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers>
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120215/0e4566d9/attachment.htm>

From julien.finet at kitware.com  Thu Feb 16 17:11:27 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Thu, 16 Feb 2012 12:11:27 -0500
Subject: [Ctk-developers] Crash in ~OFCondition()
In-Reply-To: <1785044.tr3tAlaG69@livius>
References: <CAKoWPPFuuknBqK9PG1LL5Ld+b9yxPVhyn_jXsVh5m-d8vs84xQ@mail.gmail.com>
	<4F3BBD74.6030503@dkfz.de>
	<CAKoWPPEdCHWpEJ7R0cND6Jq5G0uhnUKRcgLRbai-AdMRiPLFsw@mail.gmail.com>
	<1785044.tr3tAlaG69@livius>
Message-ID: <CAKoWPPH4M4ZU4Via4vVYENz3Qzpy-BpA2wTENZ+nS3pnjiLfZg@mail.gmail.com>

Hi Jorg,

Nice job, I tried the head of DCMTK, and the OfCondition crash disappeared.
However I'm experiencing another crash. I can reproduce in my small program
(ofConditionCrash) and in the test application ctkDICOM in CTK.

This is very odd, a static OFList is instantiated twice with the same
address  and deleted twice at the same address, therefore a crash. See
below the backtrace when I place a breakpoint in OFList() and ~OFList().
Note that the address is always the same (0xa6ea70). Btw, the address is a
32bits address, does it mean DCMTK is built in 32bits ?

I tried with a clean build of CTK. Can you eventually try that CTK branch
https://github.com/finetjul/CTK/tree/dcmtk-trunk  and see if you have a
crash when running ctkDICOM ?

Thanks,
Julien.

At startup:

First time the OFList at address 0xa6ea70 is constructed:

Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:330
330        OFList() : OFListBase() { }
(gdb) backtrace
#0  OFList<DcmCodecList*>::OFList (this=0xa6ea70)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:330
#1  0x00007ffff5711005 in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43
#2  0x00007ffff5711069 in _GLOBAL__sub_I_dccodec.cc(void) ()
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:652
#3  0x00007ffff7deab26 in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7deabff in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7ddd5ea in ?? () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe507 in ?? ()
#8  0x0000000000000000 in ?? ()

Second time the OFList at address 0xa6ea70 is constructed

Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:330
330        OFList() : OFListBase() { }
(gdb) backtrace
#0  OFList<DcmCodecList*>::OFList (this=0xa6ea70)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:330
#1  0x00000000006f997d in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43
#2  0x00000000006f99e1 in _GLOBAL__sub_I_dccodec.cc(void) ()
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:652
#3  0x00000000007469ed in __libc_csu_init ()
#4  0x00007ffff5be92a0 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00000000004b0fd9 in _start ()

When the application exits:

First time it gets into the destructor:

Breakpoint 2, OFListBase::~OFListBase (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/libsrc/oflist.cc:54
54            delete afterLast;
(gdb) backtrace
#0  OFListBase::~OFListBase (this=0xa6ea70, __in_chrg=<optimized out>)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/libsrc/oflist.cc:54
#1  0x00000000006f9cc8 in OFList<DcmCodecList*>::~OFList (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:291
#2  0x00007ffff5c03821 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff5c038a5 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff5be9314 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00000000004b0fd9 in _start ()

Second time it gets into the destructor:

(gdb) backtrace
#0  OFListBase::~OFListBase (this=0xa6ea70, __in_chrg=<optimized out>)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/libsrc/oflist.cc:54
#1  0x00000000006f9cc8 in OFList<DcmCodecList*>::~OFList (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:291
#2  0x00007ffff5c03c3d in __cxa_finalize ()
   from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff5473e06 in __do_global_dtors_aux ()
   from
/home/julien/Work/CTK/CTK-noPython/CTK-build/bin/libCTKDICOMCore.so.0.1
#4  0x00007fffffffdf00 in ?? ()
#5  0x00007fffffffe140 in ?? ()
#6  0x00007ffff5839ff1 in _fini ()
   from
/home/julien/Work/CTK/CTK-noPython/CTK-build/bin/libCTKDICOMCore.so.0.1
#7  0x00007fffffffe140 in ?? ()
#8  0x00007ffff7deb105 in ?? () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


This then leads to the following crash:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000031 in ?? ()
(gdb) up
#1  0x000000000073cb8b in OFListBase::~OFListBase (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/libsrc/oflist.cc:54
54            delete afterLast;
(gdb) backtrace
#0  0x0000000000000031 in ?? ()
#1  0x000000000073cb8b in OFListBase::~OFListBase (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at /home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/libsrc/oflist.cc:54
#2  0x00000000006f9cc8 in OFList<DcmCodecList*>::~OFList (this=0xa6ea70,
    __in_chrg=<optimized out>)
    at
/home/julien/Work/CTK/CTK-noPython/DCMTK/ofstd/include/dcmtk/ofstd/oflist.h:291
#3  0x00007ffff5c03c3d in __cxa_finalize ()
   from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff5473e06 in __do_global_dtors_aux ()
   from
/home/julien/Work/CTK/CTK-noPython/CTK-build/bin/libCTKDICOMCore.so.0.1
#5  0x00007fffffffdf00 in ?? ()
#6  0x00007fffffffe140 in ?? ()
#7  0x00007ffff5839ff1 in _fini ()
   from
/home/julien/Work/CTK/CTK-noPython/CTK-build/bin/libCTKDICOMCore.so.0.1
#8  0x00007fffffffe140 in ?? ()
#9  0x00007ffff7deb105 in ?? () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

On Wed, Feb 15, 2012 at 3:54 PM, J?rg Riesmeier <riesmeier at icsmed.de> wrote:

> Julien,
>
> > Anyway, when you guys rewrite the OfCondition code, can you please try to
> > build DCMTK in CTK and test the ofConditionCrash project
>
> I just did that on the same machine as last time: Now it works :-)
>
> Regards,
> J?rg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120216/18a9917b/attachment.htm>

From s.zelzer at dkfz-heidelberg.de  Thu Feb 16 17:34:19 2012
From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer)
Date: Thu, 16 Feb 2012 18:34:19 +0100
Subject: [Ctk-developers] Team page
In-Reply-To: <CAKoWPPHyGs7tGNBhFm=4EauVb+kitk80o+mrg1pbk-7EUWYJNg@mail.gmail.com>
References: <CAKoWPPHyGs7tGNBhFm=4EauVb+kitk80o+mrg1pbk-7EUWYJNg@mail.gmail.com>
Message-ID: <4F3D3E1B.9040301@dkfz-heidelberg.de>

Hi Julien,

Nice job!

- Sascha

On 02/15/2012 04:54 PM, Julien Finet wrote:
> Hi CTKers,
>
> I redesigned the "team" page: http://www.commontk.org/index.php/The_Team
> I especially added the "grant/funding/sponsors" section to acknowledge 
> our funding organizations.
> Please add/edit/remove missing/wrong information...
> Make sure I used the right logos for your institution/project.
>
> Feel free to reorganize the "people" section.
>
> Thanks,
> Julien.



From julien.finet at kitware.com  Fri Feb 17 16:56:18 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Fri, 17 Feb 2012 11:56:18 -0500
Subject: [Ctk-developers] Fwd: Re: Re:  Crash in ~OFCondition()
In-Reply-To: <4F3E6C2F.5030303@informatik.uni-oldenburg.de>
References: <CAKoWPPH4M4ZU4Via4vVYENz3Qzpy-BpA2wTENZ+nS3pnjiLfZg@mail.gmail.com>
	<4F3E66D4.5060603@icsmed.de>
	<4F3E6C2F.5030303@informatik.uni-oldenburg.de>
Message-ID: <CAKoWPPHhCvt7sVkVjdqPHOXT0zX4hu5EEc7-hLZa8gZyKZosZA@mail.gmail.com>

Hi Uli,

Thanks for your explanation, it starts to makes sense to me.
See at the end of the email the output I got when building with VERBOSE
mode on.
You are right when you say that the application (that links against shared
B that links against shared A that links against static DCMTK) links with
DCMTK.

When I specify in the CMakeList.txt :
a) target_link_libraries(A LINK_INTERFACE_LIBRARIES) or
b) target_link_libraries(B LINK_INTERFACE_LIBRARIES)

In a), only A links against dcmtk libs; in b), only A and B link against
dcmtk libs.

In a) and b) the main application doesn't link with DCMTK anymore and
doesn't crash either as you correctly guessed.

I wonder if the rule should be to set an empty LINK_INTERFACE_LIBRARIES for
each target that directly links to a static version of DCMTK.
That means that if a library links against A and if that library uses
symbols of DCMTK not in the link object of A, then it needs to manually
link against DCMTK and must also set the LINK_INTERFACE_LIBRARIES to "".
That seems like a fair system.

Any thoughts?

Thanks,
Julien.

$ make VERBOSE=1
...
[ 33%] Building CXX object CMakeFiles/A.dir/a.cpp.o
/usr/bin/c++   -DA_EXPORTS -fPIC -g -fPIC
-I/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/include/dcmtk/config
[...]  -o CMakeFiles/A.dir/a.cpp.o -c
/home/julien/Work/DCMTK/OfConditionCrash/src/a.cpp
Linking CXX shared library libA.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/A.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC -fPIC -g   -shared -Wl,-soname,libA.so -o libA.so
CMakeFiles/A.dir/a.cpp.o
/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/lib/libdcmimage.a
[..] -lpthread
[ 33%] Built target A
[ 66%] Building CXX object CMakeFiles/B.dir/b.cpp.o
/usr/bin/c++   -DB_EXPORTS -fPIC -g -fPIC
-I/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/include/dcmtk/config
[...]  -o CMakeFiles/B.dir/b.cpp.o -c
/home/julien/Work/DCMTK/OfConditionCrash/src/b.cpp
Linking CXX shared library libB.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/B.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC -fPIC -g   -shared -Wl,-soname,libB.so -o libB.so
CMakeFiles/B.dir/b.cpp.o libA.so
/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/lib/libdcmimage.a
[..] -lpthread
-Wl,-rpath,/home/julien/Work/DCMTK/OfConditionCrash/build-ctk
[ 66%] Built target B
[100%] Building CXX object CMakeFiles/ofConditionCrash.dir/main.cpp.o
/usr/bin/c++    -fPIC -g
-I/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/include/dcmtk/config
[...] -o CMakeFiles/ofConditionCrash.dir/main.cpp.o -c
/home/julien/Work/DCMTK/OfConditionCrash/src/main.cpp
Linking CXX executable ofConditionCrash
/usr/bin/c++   -fPIC -g    CMakeFiles/ofConditionCrash.dir/main.cpp.o  -o
ofConditionCrash -rdynamic libB.so libA.so
/home/julien/Work/CTK/CTK-noPython/CMakeExternals/Install/lib/libdcmimage.a
[...] -lpthread
-Wl,-rpath,/home/julien/Work/DCMTK/OfConditionCrash/build-ctk
[100%] Built target ofConditionCrash

On Fri, Feb 17, 2012 at 10:03 AM, Uli Schlachter <
Uli.Schlachter at informatik.uni-oldenburg.de> wrote:

> Hi everyone,
>
> > Nice job, I tried the head of DCMTK, and the OfCondition crash
> disappeared.
> > However I'm experiencing another crash. I can reproduce in my small
> program
> > (ofConditionCrash) and in the test application ctkDICOM in CTK.
> >
> > This is very odd, a static OFList is instantiated twice with the same
> > address  and deleted twice at the same address, therefore a crash. See
> below
> > the backtrace when I place a breakpoint in OFList() and ~OFList(). Note
> that
> > the address is always the same (0xa6ea70).
> [...]
>
> (I shortened and modified the following backtraces to make this more
> readable)
>
> > First time the OFList at address 0xa6ea70 is constructed:
> >
> > Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)
> > (gdb) backtrace
> > #0  OFList<DcmCodecList*>::OFList (this=0xa6ea70)
> > #1  0x00007ffff5711005 in __static_initialization_and_destruction_0 ()
> >       at
> /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43
> > #2  0x00007ffff5711069 in _GLOBAL__sub_I_dccodec.cc(void) ()
> > #3  0x00007ffff7deab26 in ?? () from /lib64/ld-linux-x86-64.so.2
> >
> > Second time the OFList at address 0xa6ea70 is constructed
> >
> > Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)
> > 330        OFList() : OFListBase() { }
> > (gdb) backtrace
> > #0  OFList<DcmCodecList*>::OFList (this=0xa6ea70)
> > #1  0x00000000006f997d in __static_initialization_and_destruction_0 ()
> >       at
> /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43
> > #2  0x00000000006f99e1 in _GLOBAL__sub_I_dccodec.cc(void) ()
> > #3  0x00000000007469ed in __libc_csu_init ()
> > #4  0x00007ffff5be92a0 in __libc_start_main ()
> >      from /lib/x86_64-linux-gnu/libc.so.6
> > #5  0x00000000004b0fd9 in _start ()
> [...]
>
> This looks a lot like DCMTK ended up twice in the application. Just to be
> sure
> that I didn't get anything wrong:
>
> - This is the test from ofConditionCrash.tar.gz from Julien Finet.
> - We have two shared libraries (A and B) and the main application.
> - main links against B, B links against A
> - A links against a *static* version of the DCMTK
>
> The above backtrace looks to me as if this static version of the DCMTK was
> linked in more than once. The first call to the constructor of
> DcmCodecList::registeredCodecs is done by the dynamic linker, hence this
> should
> be the constructor which is registered inside of library A. The second
> call is
> done (indirectly) by __libc_start_main. I think this is when the list of
> the
> main application's static constructors is run.
>
> I hear you ask "But if DCMTK is linked in twice, shouldn't the two version
> be at
> different addresses?". Yes, that is correct. However, both copies export
> the
> same symbols. The dynamic linker now tries to fix up that mess and
> (re-)links
> everything against one of the versions. Judging from the pointer, I'd say
> that
> the DCMTK copy in the main application won.
>
> Since I have some problems with FindDCMTK (no installed version of DCMTK
> laying
> around), could someone compile the test from ofConditionCrash.tar.gz with
> cmake
> and run the resulting makefiles with "make VERBOSE=1"? I bet the output
> will
> show that CMake links ofConditionCrash against DCMTK, too.
>
> A quick look into the CMake docs found the following possible explanation
> in the
> docs for target_link_libraries():
>
>   Library dependencies are transitive by default. When this target is
> linked
>   into another target then the libraries linked to this target will appear
> on
>   the link line for the other target too.
>
> If I am correct, my preferred solution would be not to use static
> libraries when
> building DCMTK. The linker will never try to link in a dynamic library
> more than
> once. :-)
>
> Cheers,
> Uli
>
> --
> my $key =
> "\x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5".
>
>  "\x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93";
> my $cipher = Crypt::Rijndael->new( $key, Crypt::Rijndael::MODE_ECB() );
> my $plain = $ciper->decrypt($daten);
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120217/3701c92b/attachment.htm>

From julien.finet at kitware.com  Tue Feb 21 19:52:28 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Tue, 21 Feb 2012 14:52:28 -0500
Subject: [Ctk-developers] Fwd: Re: Re:  Crash in ~OFCondition()
In-Reply-To: <4F3E8BAA.9080908@informatik.uni-oldenburg.de>
References: <CAKoWPPH4M4ZU4Via4vVYENz3Qzpy-BpA2wTENZ+nS3pnjiLfZg@mail.gmail.com>
	<4F3E66D4.5060603@icsmed.de>
	<4F3E6C2F.5030303@informatik.uni-oldenburg.de>
	<CAKoWPPHhCvt7sVkVjdqPHOXT0zX4hu5EEc7-hLZa8gZyKZosZA@mail.gmail.com>
	<4F3E8BAA.9080908@informatik.uni-oldenburg.de>
Message-ID: <CAKoWPPF-hqfOxw6XrDj-iDt7bV_mpC5hzb-g33cR804r9D9hJw@mail.gmail.com>

Hi Uli,

On Fri, Feb 17, 2012 at 12:17 PM, Uli Schlachter <
Uli.Schlachter at informatik.uni-oldenburg.de> wrote:

> Hi Julien,
>
> On 17.02.2012 17:56, Julien Finet wrote:
> > You are right when you say that the application (that links against
> shared
> > B that links against shared A that links against static DCMTK) links with
> > DCMTK.
>
> Thanks for confirming. So the only mystery left is "Why didn't B call the
> static
> constructor/destructor, too? It should have!".

I don't know, it's a mystery indeed.


>  > I wonder if the rule should be to set an empty LINK_INTERFACE_LIBRARIES
> for

> each target that directly links to a static version of DCMTK.
> > That means that if a library links against A and if that library uses
> > symbols of DCMTK not in the link object of A, then it needs to manually
> > link against DCMTK and must also set the LINK_INTERFACE_LIBRARIES to "".
> > That seems like a fair system.
>
That doesn't really solve the problem, it just makes it harder to hit. Let's
> introduce a new library C which does not link against A or B, but does use
> dcmimage, too. It will have to be statically linked against DCMTK, too.
> With
> some "luck", the crash will re-appear.
>
Good catch, I tried and I have a crash. So let's forget about that idea :-)


> Alternatively, your idea with "and if that library uses symbols of DCMTK
> not in
> the link object of A" has the same problem. If both libs happen to include
> dccodec.o, then the result will call the destructor twice again.


> In my opinion, the only solution which avoids all of these problems is
> "built
> DCMTK into shared libraries". Linking a static library into a shared
> library and
> exporting its symbols just asks for symbol collisions and lots of problems.
>
I don't have a problem with building DCMTK as shared. Do you guys confirm
DCMTK builds fine as a shared library on Windows (visual studio (express)
2008, 2010), Linux (ubuntu, fedora, debian in 32b or 64b) and Mac (> OS X
10.5)

Benoit mentioned he had troubles to build some older version of DCMTK as
shared on Windows. I'll give a try on my machines.


> The only way to solve symbol collisions is not to have symbol collisions.
> ;-)
>
> BTW: How come this compiles at all? Static libraries are not built with
> "-fpic"
> (AFAIK) and on amd64 this means that it cannot be linked into a shared
> library.
>
Static libraries can be built with fpic on AMD64, this is why in CTK we
turn the DCTMK_FORCE_FPIC_ON_UNIX cmake option when building DCMTK. It
would otherwise fail to link fPIC enabled CTK libraries with DCMTK.


>
> Another BTW: Linking with a static library twice is always wrong. Could
> this
> count as a bug in CMake which needs to be fixed? Since you have a "@
> kitware.com"
> mail address, I'll let you decide. :-)
>
I guess it's ok to link with a static library more than once if there is no
global static symbols exported in the static library.


>
> Cheers,
> Uli
>
Thanks for your help,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120221/489f7bba/attachment.htm>

From julien.finet at kitware.com  Wed Feb 22 07:28:55 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Wed, 22 Feb 2012 02:28:55 -0500
Subject: [Ctk-developers] Fwd: Re: Re:  Crash in ~OFCondition()
In-Reply-To: <CAKoWPPF-hqfOxw6XrDj-iDt7bV_mpC5hzb-g33cR804r9D9hJw@mail.gmail.com>
References: <CAKoWPPH4M4ZU4Via4vVYENz3Qzpy-BpA2wTENZ+nS3pnjiLfZg@mail.gmail.com>
	<4F3E66D4.5060603@icsmed.de>
	<4F3E6C2F.5030303@informatik.uni-oldenburg.de>
	<CAKoWPPHhCvt7sVkVjdqPHOXT0zX4hu5EEc7-hLZa8gZyKZosZA@mail.gmail.com>
	<4F3E8BAA.9080908@informatik.uni-oldenburg.de>
	<CAKoWPPF-hqfOxw6XrDj-iDt7bV_mpC5hzb-g33cR804r9D9hJw@mail.gmail.com>
Message-ID: <CAKoWPPGzf_nxRgjVczx_7tVAtkkCxyoWTGUmXnuz620RboGfjQ@mail.gmail.com>

For information, I successfully built CTK with DCMTK trunk as shared on
Windows.
I tried: VS Express 2008 32bits, VS 2008 32bits, VS 2008 64bits and VS2010
64bits.

However, I would need to investigate a bit more to see what's missing (if
anything missing) for the install rules. In any ways Slicer would need to
be updated to copy the dlls in the right directory and fixup bundle on Mac.

Julien.

On Tue, Feb 21, 2012 at 2:52 PM, Julien Finet <julien.finet at kitware.com>wrote:

> Hi Uli,
>
> On Fri, Feb 17, 2012 at 12:17 PM, Uli Schlachter <
> Uli.Schlachter at informatik.uni-oldenburg.de> wrote:
>
>> Hi Julien,
>>
>> On 17.02.2012 17:56, Julien Finet wrote:
>> > You are right when you say that the application (that links against
>> shared
>> > B that links against shared A that links against static DCMTK) links
>> with
>> > DCMTK.
>>
>> Thanks for confirming. So the only mystery left is "Why didn't B call the
>> static
>> constructor/destructor, too? It should have!".
>>
> I don't know, it's a mystery indeed.
>
>
>>  > I wonder if the rule should be to set an empty
>> LINK_INTERFACE_LIBRARIES for
>
> > each target that directly links to a static version of DCMTK.
>> > That means that if a library links against A and if that library uses
>> > symbols of DCMTK not in the link object of A, then it needs to manually
>> > link against DCMTK and must also set the LINK_INTERFACE_LIBRARIES to "".
>> > That seems like a fair system.
>>
> That doesn't really solve the problem, it just makes it harder to hit.
>> Let's
>>
>> introduce a new library C which does not link against A or B, but does use
>> dcmimage, too. It will have to be statically linked against DCMTK, too.
>> With
>> some "luck", the crash will re-appear.
>>
> Good catch, I tried and I have a crash. So let's forget about that idea :-)
>
>
>> Alternatively, your idea with "and if that library uses symbols of DCMTK
>> not in
>> the link object of A" has the same problem. If both libs happen to include
>> dccodec.o, then the result will call the destructor twice again.
>
>
>> In my opinion, the only solution which avoids all of these problems is
>> "built
>> DCMTK into shared libraries". Linking a static library into a shared
>> library and
>> exporting its symbols just asks for symbol collisions and lots of
>> problems.
>>
> I don't have a problem with building DCMTK as shared. Do you guys confirm
> DCMTK builds fine as a shared library on Windows (visual studio (express)
> 2008, 2010), Linux (ubuntu, fedora, debian in 32b or 64b) and Mac (> OS X
> 10.5)
>
> Benoit mentioned he had troubles to build some older version of DCMTK as
> shared on Windows. I'll give a try on my machines.
>
>
>> The only way to solve symbol collisions is not to have symbol collisions.
>> ;-)
>>
>> BTW: How come this compiles at all? Static libraries are not built with
>> "-fpic"
>> (AFAIK) and on amd64 this means that it cannot be linked into a shared
>> library.
>>
> Static libraries can be built with fpic on AMD64, this is why in CTK we
> turn the DCTMK_FORCE_FPIC_ON_UNIX cmake option when building DCMTK. It
> would otherwise fail to link fPIC enabled CTK libraries with DCMTK.
>
>
>>
>> Another BTW: Linking with a static library twice is always wrong. Could
>> this
>> count as a bug in CMake which needs to be fixed? Since you have a "@
>> kitware.com"
>> mail address, I'll let you decide. :-)
>>
> I guess it's ok to link with a static library more than once if there is
> no global static symbols exported in the static library.
>
>
>>
>> Cheers,
>> Uli
>>
> Thanks for your help,
> Julien.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120222/013b3de8/attachment.htm>

From julien.finet at kitware.com  Thu Feb 23 17:44:58 2012
From: julien.finet at kitware.com (Julien Finet)
Date: Thu, 23 Feb 2012 12:44:58 -0500
Subject: [Ctk-developers] Slicer webinar
Message-ID: <CAKoWPPGym2SZEZS13DSH=sOj76Qap_aANCaD9kB51dK7nHhrwQ@mail.gmail.com>

We're happy to announce that we will be hosting an online introductory
Slicer course on Tuesday, February 28, 2012 12:30 PM - 2:00 PM EST

This course provides an introduction to the open-source 3DSlicer
application, designed for first time users who are interested in a broad
overview of Slicer's features and tools. The course introduces and
demonstrates core functionalities such as loading, visualizing and saving
data. Basic processing tools, including manual registration, manual
segmentation and tractography tools are also highlighted. This course is
not an exhaustive or in depth review of all the capabilities of Slicer nor
a tutorial for developers.

Julien Finet will be teaching the course; Dr. Steve Pieper and
Jean-Christophe Fillion-Robin will be attending to answer any questions
during the course.

To attend, please visit the registration
page<https://www3.gotomeeting.com/register/816969742>.
If you have any question, please do not hesitate to ask.

Thanks,
Julien Finet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20120223/a3646165/attachment.htm>

From curzio at camelotbio.com  Wed Feb 29 13:54:41 2012
From: curzio at camelotbio.com (Curzio Basso)
Date: Wed, 29 Feb 2012 14:54:41 +0100
Subject: [Ctk-developers] problem compiling dcmtk
Message-ID: <78F2BADB-3198-43D8-86A2-0ABCBA9796E5@camelotbio.com>


Hi,

I seem to have a problem compiling the superbuild. Namely I get the following
error while compiling DCMTK:

[ 28%] Building CXX object dcmimgle/libsrc/CMakeFiles/dcmimgle.dir/dimoimg.o
In file included from /Users/basso/work/CAMELOT/External/CTK-superbuild-20120229/DCMTK/dcmimgle/libsrc/dimoimg.cc:38:
/Users/basso/work/CAMELOT/External/CTK-superbuild-20120229/DCMTK/dcmimgle/include/dcmtk/dcmimgle/dimosct.h:127:17: error: 
      use of undeclared identifier 'scaleData'
                scaleData(&pixel, &this->Data, interpolate, value);
                ^
                this->
/Users/basso/work/CAMELOT/External/CTK-superbuild-20120229/DCMTK/dcmimgle/include/dcmtk/dcmimgle/dimosct.h:91:17: note: 
      in instantiation of member function 'DiMonoScaleTemplate<unsigned
      char>::scale' requested here
                scale(OFstatic_cast(const T *, pixel->getData()), ...
                ^
[snip]

and more of the following (I can attach the complete output if needed).

The source has been cloned right now from the repository, and I am using gcc 4.2 on a
mac. Is it a problem upstream? Can be reproduced?

thanks for any info
curzio

--
Curzio Basso, Ph.D
CAMELOT Biomedical Systems Srl
Via Greto di Cornigliano 6R
16152 Genova, Italy

+39-010-8695741 (office)
+39-010-8695742 (fax)
+39-349-5972038 (mobile)



From onken at offis.de  Wed Feb 29 15:41:50 2012
From: onken at offis.de (Michael Onken)
Date: Wed, 29 Feb 2012 16:41:50 +0100
Subject: [Ctk-developers] problem compiling dcmtk
In-Reply-To: <78F2BADB-3198-43D8-86A2-0ABCBA9796E5@camelotbio.com>
References: <78F2BADB-3198-43D8-86A2-0ABCBA9796E5@camelotbio.com>
Message-ID: <4F4E473E.9070404@offis.de>

Hi Curzio,

On 29.02.2012 14:54, Curzio Basso wrote:
> Hi,
>
> I seem to have a problem compiling the superbuild. Namely I get the
> following error while compiling DCMTK: [...]
> use of undeclared identifier 'scaleData'
> scaleData(&pixel,&this->Data, interpolate, value); ^ this->
> /Users/basso/work/CAMELOT/External/CTK-superbuild-20120229/DCMTK/dcmimgle/include/dcmtk/dcmimgle/dimosct.h:91:17:
> note: in instantiation of member function
> 'DiMonoScaleTemplate<unsigned char>::scale' requested here
> scale(OFstatic_cast(const T *, pixel->getData()), ... ^ [snip]

This problem has been fixed meanwhile in DCMTK (see commit [1]). You 
might try the latest DCMTK code or apply a local patch.

Best regards,
Michael

[1] 
http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=dbadc0d8f3760f65504406c8b2cb8633f868a258

-- 
Dipl.-Inform. Michael Onken
FuE Bereich Gesundheit | R&D Division Health

OFFIS
FuE Bereich Gesundheit | R&D Division Health
Escherweg 2 - 26121 Oldenburg - Germany
Phone/Fax.: +49 441 9722-149/111
E-Mail: onken at offis.de
URL: http://www.offis.de