[Ctk-developers] Fwd: Re: Re: Crash in ~OFCondition()

[Julien Finet]

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.html>