For information, I successfully built CTK with DCMTK trunk as shared on Windows. <div>I tried: VS Express 2008 32bits, VS 2008 32bits, VS 2008 64bits and VS2010 64bits.</div><div><br></div><div>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. </div>
<div><br></div><div>Julien. <br><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 2:52 PM, Julien Finet <span dir="ltr"><<a href="mailto:julien.finet@kitware.com">julien.finet@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Uli,<br><br><div class="gmail_quote"><div class="im">On Fri, Feb 17, 2012 at 12:17 PM, Uli Schlachter <span dir="ltr"><<a href="mailto:Uli.Schlachter@informatik.uni-oldenburg.de" target="_blank">Uli.Schlachter@informatik.uni-oldenburg.de</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Julien,<br>
<div><div class="im"><br>
On 17.02.2012 17:56, Julien Finet wrote:<br></div><div class="im">> You are right when you say that the application (that links against shared<br>
> B that links against shared A that links against static DCMTK) links with<br>
> DCMTK.<br>
<br>
</div></div><div class="im">Thanks for confirming. So the only mystery left is "Why didn't B call the static<br>
constructor/destructor, too? It should have!".</div></blockquote><div>I don't know, it's a mystery indeed.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I wonder if the rule should be to set an empty LINK_INTERFACE_LIBRARIES for</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> each target that directly links to a static version of DCMTK.<br>
> That means that if a library links against A and if that library uses<br>
> symbols of DCMTK not in the link object of A, then it needs to manually<br>
> link against DCMTK and must also set the LINK_INTERFACE_LIBRARIES to "".<br>
> That seems like a fair system. </div></blockquote></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div>
That doesn't really solve the problem, it just makes it harder to hit. Let's<div class="im"><br>
introduce a new library C which does not link against A or B, but does use<br>
dcmimage, too. It will have to be statically linked against DCMTK, too. With<br>
some "luck", the crash will re-appear.<br></div></blockquote><div>Good catch, I tried and I have a crash. So let's forget about that idea :-)</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternatively, your idea with "and if that library uses symbols of DCMTK not in<br>
the link object of A" has the same problem. If both libs happen to include<br>
dccodec.o, then the result will call the destructor twice again. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In my opinion, the only solution which avoids all of these problems is "built<br>
DCMTK into shared libraries". Linking a static library into a shared library and<br>
exporting its symbols just asks for symbol collisions and lots of problems.<br></blockquote></div><div>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)</div>
<div><br></div><div>Benoit mentioned he had troubles to build some older version of DCMTK as shared on Windows. I'll give a try on my machines. </div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The only way to solve symbol collisions is not to have symbol collisions. ;-)<br>
<br>
BTW: How come this compiles at all? Static libraries are not built with "-fpic"<br>
(AFAIK) and on amd64 this means that it cannot be linked into a shared library.<br></blockquote></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another BTW: Linking with a static library twice is always wrong. Could this<br>
count as a bug in CMake which needs to be fixed? Since you have a "@<a href="http://kitware.com" target="_blank">kitware.com</a>"<br>
mail address, I'll let you decide. :-)<br></blockquote></div><div>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.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Uli<br></blockquote><div>Thanks for your help,</div><div>Julien. </div></div><br>
</blockquote></div><br></div>