Re: Ginkgo-CADx segfaults
On Friday, November 11, 2011 10:42:23 PM Mathieu Malaterre wrote:
> On Fri, Nov 11, 2011 at 10:26 PM, Sebastian Hilbert
>
> <sebastian.hilbert@gmx.net> wrote:
> > On Friday, November 11, 2011 09:42:23 PM Mathieu Malaterre wrote:
> >> On Fri, Nov 11, 2011 at 6:12 PM, Sebastian Hilbert
> >>
> >> <sebastian.hilbert@gmx.net> wrote:
> >> > On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote:
> >> >> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote:
> >> >> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:
> >> >> > > Sorry for saying the obvious here, but if the bug is not
> >> >> > > Debian-specific, then it should go to ITK upstream.
> >> >>
> >> >> I definitely encourage that patches for upstream bugs be sent
> >> >> upstream.
> >> >>
> >> >> > The question was more along the lines if Debian packages accept
> >> >> > patches which upstream refuses (have not checked with upstream ITK
> >> >> > but have had issues with wxwidgets).
> >> >>
> >> >> It's common for Debian to have patches not in upstream. Often, in my
> >> >> experience, it's not because of upstream refusal but due to differing
> >> >> priority or differing release cycles. I generally have a number of
> >> >> patches for Boost that upstream takes multiple releases to
> >> >> incorporate.
> >> >>
> >> >> If you have a patch for the problem, I encourage you to submit a
> >> >> Debian bug report as well as the upstream one, and link them.
> >> >
> >> > Raising this problem upstream at Ginkgo I was pointed to
> >> >
> >> > this bug report against itk upstream
> >> >
> >> > https://itk.icts.uiowa.edu/jira/browse/ITK-2457
> >> >
> >> > The comment from Mathieu there made me check which gdcm
> >> > libinsighttolkit depends on in Debian
> >> >
> >> > http://packages.debian.org/sid/libinsighttoolkit3.20
> >> >
> >> > This however indicates that it already depends on gdcm 2.x
> >> >
> >> > which in turn means the bug is not fixed ?
> >> >
> >> > Supposedly most work is on itk4 which might make the problem go away.
> >>
> >> That's correct. ITK in debian has not been using the old GDCM 1.x
> >> where a static buffer was used to decompress JPEG segment since years.
> >> ITK uses a thread safe implementation in GDCM 2.x. I would think the
> >> issue is not the one described in bug ITK-2457
> >>
> >> HTH
> >
> > Now that I think of it upstream release 2.6.0 seems to work better. I
> > will follow up on this when this is packaged for Debian.
> >
> > Has the patch mentioned ever made it into ITK ?
>
> There is no "patch" per-say. ITK policy is very strict with regards to
> backward compatible API. Unfortunately GDCM 2.x did break quite a lot
> of GDCM 1.x API. Since the low level GDCM API was used so much, it was
> considered that breaking GDCM API would mean breaking ITK API, and
> thus never made it officially into ITK. ITKv4 effort was specifically
> designed with this goal in mind: break the API and cleanup old cruft.
>
> Because I needed better DICOM functionalities in ITK, I made an option
> 'system GDCM' from the ITK configuration which allowed advanced users
> to compile ITK against both a GDCM 1.x and GDCM 2.x API.
>
> I believe there has been a first rc for ITKv4, so this issue should
> soon be solved.
>
I will wait for that. Thanks for the info.
There seems to be another issue in that Ginkgo-CADx from Unstable uses
libinsighttoolkit3.20.
Ginkgo cannot open a dicom file I have available since updating from
libinsighttoolkit3.18 to 3.20.
I will raise this issue upstream.
Regards,
Sebastian
> HTH
Reply to: