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

[Julien Finet]

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