[Ctk-developers] CTK Update to latest DCMTK

[Jean-Christophe Fillion-Robin]

On Mon, Aug 1, 2011 at 1:00 PM, OFFIS DICOM Team <dicom at offis.de> wrote:

> Hi,
>
> Am 01.08.2011 18:25, schrieb Jean-Christophe Fillion-Robin:
>
>  Regarding MT and /MTd, would it make sens to have a CMake option named
>> DCMTK_MULTITHREADED ?
>>
>
> If CMake automatically uses the flags it should and hands it over to all
> external projects, this would be not needed. However, I'm not sure whether
> this is actually the case.
>

CMake could pass down any additional flags by configuring the project with
CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.



>
> We already have a WITH_THREADS flag in DCMTK which adds libpthread if
> existing/necessary. Usually, with threads is turned on.


Does it mean that turning WITH_THREAD OFF won't append the /MT or /MTd flags
?


>
>
>  Yes, and totally my fault ;)
>>
>>
>> No prob :) Seems we identify and are on the good track to get the problem
>> fixed.
>>
>
> Yes, I hope so :)
>
>
>
>> DCMTK build by CTK is/was broken. The flag fPIC was not added
>> automatically ...
>>
>
> Yes, ok; as I understood this is needed when linking against the shared
> DCMTK libraries from outside.

This happen when linking a shared 64bits library against  a static library.
The fPIC flag is required.

>
>
>  * Get write access to official dcmtk ? * Ask dcmtk folks to mirror DCMTK
>> on github so that we can fork and easily contribute patches ? * Mirror
>> DCMTK ourself on commontk/dcmtk
>>
>>
>> I would not be happy about any of these. Let's get things running on all
>> platforms now; I will do my part as good as possible and with priority.
>> Then we can take a fixed commit and update that from time to time in CTK.
>> We can do that regulary, as you like, or as I can give you a hint if
>> interesting features (for CTK) come in.
>>
>>
>> I guess submitting patch to Offis directly seems to be the way to go. We
>>  could also publish our topic branch on commontk/DCMTK to that you can
>> review them before final integration upstream.
>>
>
> Fine for me. My point is just that we should not let drift apart CTK too
> much from the latest DCMTK version. Otherwise (like now..;)) it is double
> work to align things again :)

Excellent - And thanks for helping us catching up with the current DCMTK.


>
>  Assigned issue https://github.com/commontk/__**CTK/issues/22<https://github.com/commontk/__CTK/issues/22>
>> <https://github.com/commontk/**CTK/issues/22<https://github.com/commontk/CTK/issues/22>>
>> to Michael
>>
>> In the mean time, I will update CMakeExternal/DCMTK.cmake so that fPIC is
>> passed.
>>
>>
>> Shouldn't we not just change DCMTK's CMakeLists.txt? We need these flags
>> anyway sooner or later, so we should also take it over. I would just take
>> over the solution from the link (issues/22) into DCMTK's CMakeLists.txt.
>>
>>
>> Very true - i didn't know how responsive you would be. Do you know when
>> things will be fixed?
>>
>
> I could commit it any time/immediately in DCMTK. My colleague noted that we
> should take care that we only put -fPIC into effect if it is understood by
> the compiler and needed, so I wonder whether "IF(UNIX" is a sufficient
> guard. Any hints or recommendations?


You could for example do:

#-----------------------------------------------------------------------------
# To fix compilation problem: relocation R_X86_64_32 against `a local
symbol' can not be
# used when making a shared object; recompile with -fPIC
# See http://www.cmake.org/pipermail/cmake/2007-May/014350.html
#
IF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )
  SET_TARGET_PROPERTIES(log4qt PROPERTIES COMPILE_FLAGS "-fPIC")
ENDIF( CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64" )




>
> Best regards,
> Michael
>
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110801/aa673cc0/attachment.html>