severity 510120 serious thanks On Tue, Dec 30, 2008 at 4:30 PM, Juergen Salk <[email protected]> wrote: > * Mathieu Malaterre <[email protected]> [081230 10:17]: > >> > I simply cannot reproduce the problem you described above. For me all dsr* >> > applications that are part of the dcmtk package seems to be able to load >> > libdcmsr without any problems ... >> >> Correct. I did not realize it was the responsability of the >> application to do the full linking and provide libraries for the >> missing symbols. > > Yes. Unfortunately the dcmtk library build system does not link > its shared libraries with the shared libraries it depends on. I > am fully aware that this is not exactly desirable. The underlying > reason for this is the totally unconventional dcmtk build system > which is inherently much more inflexible than the standard GNU > build system (including libtool). Actually, the upstream build > system does not support building shared libraries at all (!) and > it needed some some amount of kludgy "magic" to work around all > these problems in order to provide shared libraries for Debian. > This appeared to be the best balance between what is desireable > and what is actually doable with reasonable efforts (i.e. without > adding even more - potentially error prone - complexity to > upstreams build system). > > I have met the OFFIS team personally a couple of months ago and > took the chance to briefly discuss this issue with them. > Unfortunately they are not going to change their build system > (e.g. by introducing libtool) for the upcoming dcmtk release ...
I can understand the position for upstream but what really makes me nervous is that we wont detect any ABI/API change. For instance: $ apt-cache show libdcmtk2 [...] Depends: libc6 (>= 2.3.2), libgcc1 (>= 1:4.1.1) We should have it somewhere that libdcmtk2 as uploaded is using ABI X.Y of libxml2. Thus setting severity to serious. Thanks -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
