Hi Uli,<br><br>Thanks for your explanation, it starts to makes sense to me.<br>See at the end of the email the output I got when building with VERBOSE mode on.<br>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.<br>
<br>When I specify in the CMakeList.txt :<br>a) target_link_libraries(A LINK_INTERFACE_LIBRARIES) or<br>b) target_link_libraries(B LINK_INTERFACE_LIBRARIES)<br><br>In a), only A links against dcmtk libs; in b), only A and B link against dcmtk libs.<br>
<br>In a) and b) the main application doesn't link with DCMTK anymore and doesn't crash either as you correctly guessed. <br><br>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.<br>
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.<br>
<br>Any thoughts?<br><br>Thanks,<br>Julien.<br><br>$ make VERBOSE=1<br>...<br>[ 33%] Building CXX object CMakeFiles/A.dir/a.cpp.o<br>
/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<br>Linking CXX shared library libA.so<br>
/usr/bin/cmake -E cmake_link_script CMakeFiles/A.dir/link.txt --verbose=1<br>/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 <br>
[ 33%] Built target A<br>[ 66%] Building CXX object CMakeFiles/B.dir/b.cpp.o<br>/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<br>
Linking CXX shared library libB.so<br>/usr/bin/cmake -E cmake_link_script CMakeFiles/B.dir/link.txt --verbose=1<br>/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 <br>
[ 66%] Built target B<br>[100%] Building CXX object CMakeFiles/ofConditionCrash.dir/main.cpp.o<br>/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<br>
Linking CXX executable ofConditionCrash<br>/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 <br>
[100%] Built target ofConditionCrash<br><br><div class="gmail_quote">
On Fri, Feb 17, 2012 at 10:03 AM, 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<div><br>
> Nice job, I tried the head of DCMTK, and the OfCondition crash disappeared.<br>
> However I'm experiencing another crash. I can reproduce in my small program<br>
> (ofConditionCrash) and in the test application ctkDICOM in CTK.<br>
><br>
> This is very odd, a static OFList is instantiated twice with the same<br>
> address and deleted twice at the same address, therefore a crash. See below<br>
> the backtrace when I place a breakpoint in OFList() and ~OFList(). Note that<br>
> the address is always the same (0xa6ea70).<br>
</div>[...]<br>
<br>
(I shortened and modified the following backtraces to make this more readable)<br>
<div><br>
> First time the OFList at address 0xa6ea70 is constructed:<br>
><br>
> Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)<br>
</div><div>> (gdb) backtrace<br>
> #0 OFList<DcmCodecList*>::OFList (this=0xa6ea70)<br>
</div>> #1 0x00007ffff5711005 in __static_initialization_and_destruction_0 ()<br>
<div>> at /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43<br>
> #2 0x00007ffff5711069 in _GLOBAL__sub_I_dccodec.cc(void) ()<br>
</div><div>> #3 0x00007ffff7deab26 in ?? () from /lib64/ld-linux-x86-64.so.2<br>
><br>
</div><div>> Second time the OFList at address 0xa6ea70 is constructed<br>
><br>
> Breakpoint 1, OFList<DcmCodecList*>::OFList (this=0xa6ea70)<br>
</div><div>> 330 OFList() : OFListBase() { }<br>
> (gdb) backtrace<br>
> #0 OFList<DcmCodecList*>::OFList (this=0xa6ea70)<br>
</div>> #1 0x00000000006f997d in __static_initialization_and_destruction_0 ()<br>
<div>> at /home/julien/Work/CTK/CTK-noPython/DCMTK/dcmdata/libsrc/dccodec.cc:43<br>
> #2 0x00000000006f99e1 in _GLOBAL__sub_I_dccodec.cc(void) ()<br>
</div><div>> #3 0x00000000007469ed in __libc_csu_init ()<br>
> #4 0x00007ffff5be92a0 in __libc_start_main ()<br>
> from /lib/x86_64-linux-gnu/libc.so.6<br>
> #5 0x00000000004b0fd9 in _start ()<br>
</div>[...]<br>
<br>
This looks a lot like DCMTK ended up twice in the application. Just to be sure<br>
that I didn't get anything wrong:<br>
<br>
- This is the test from ofConditionCrash.tar.gz from Julien Finet.<br>
- We have two shared libraries (A and B) and the main application.<br>
- main links against B, B links against A<br>
- A links against a *static* version of the DCMTK<br>
<br>
The above backtrace looks to me as if this static version of the DCMTK was<br>
linked in more than once. The first call to the constructor of<br>
DcmCodecList::registeredCodecs is done by the dynamic linker, hence this should<br>
be the constructor which is registered inside of library A. The second call is<br>
done (indirectly) by __libc_start_main. I think this is when the list of the<br>
main application's static constructors is run.<br>
<br>
I hear you ask "But if DCMTK is linked in twice, shouldn't the two version be at<br>
different addresses?". Yes, that is correct. However, both copies export the<br>
same symbols. The dynamic linker now tries to fix up that mess and (re-)links<br>
everything against one of the versions. Judging from the pointer, I'd say that<br>
the DCMTK copy in the main application won.<br>
<br>
Since I have some problems with FindDCMTK (no installed version of DCMTK laying<br>
around), could someone compile the test from ofConditionCrash.tar.gz with cmake<br>
and run the resulting makefiles with "make VERBOSE=1"? I bet the output will<br>
show that CMake links ofConditionCrash against DCMTK, too.<br>
<br>
A quick look into the CMake docs found the following possible explanation in the<br>
docs for target_link_libraries():<br>
<br>
Library dependencies are transitive by default. When this target is linked<br>
into another target then the libraries linked to this target will appear on<br>
the link line for the other target too.<br>
<br>
If I am correct, my preferred solution would be not to use static libraries when<br>
building DCMTK. The linker will never try to link in a dynamic library more than<br>
once. :-)<br>
<br>
Cheers,<br>
Uli<br>
<span><font color="#888888"><br>
--<br>
my $key = "\x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5".<br>
"\x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93";<br>
my $cipher = Crypt::Rijndael->new( $key, Crypt::Rijndael::MODE_ECB() );<br>
my $plain = $ciper->decrypt($daten);<br>
</font></span></blockquote></div><br>