Bug#789931: tag this as wontfix/severity normal

[Paul Yushkevich]

Thanks, Gert

I would recommend moving to itksnap 3.4 as soon as possible. This is a much
"better" release.

One caveat for 3.4 is that on Linux it should be built against qt4, not
qt5.

Thanks!
Paul

On Mon, Jan 11, 2016 at 5:48 AM, Gert Wollny  wrote:

> tags 789931 wontfix
> severity 789931 severity
> thanks
>
> The bug was reported against version 2.2.0 which is outdated, version
> 3.2.0 now builds find on all architectures that are supported by the
> insighttoolkit4.
>
> On the other hand,  the bug reports build failure on arm64 - this is an
> arch that is not (yet) supported by insighttoolkit4 and the arch
> support depends on upstream. Hence the downgrade and tag.
>
> Bast,
> Gert
>
>


-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#789931: itksnap: FTBFS in unstable

[Paul Yushkevich]

It looks like the ITK-SNAP build does not find the ITK directory.

This is a pretty outdated version, we are up to 3.2 now...

Paul

On Thu, Jun 25, 2015 at 12:38 PM, Edmund Grimley Evans 
edmund.grimley.ev...@gmail.com wrote:

 Source: itksnap
 Version: 2.2.0-1.1
 Severity: serious

 You can see the log from the recent build failure on arm64 here:

 https://buildd.debian.org/status/package.php?p=itksnapsuite=sid

 I got the same error on amd64.




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Hi Michael,

Please try setting the CMAKE_PREFIX_PATH to
[PATH_TO_QT_INSTALLATION]/lib/cmake

In my case that's /opt/Qt/5.3/gcc_64/lib/cmake

This can be provided to Cmake with the -D command, or set in the
environment.

Please let me know if that helps

Thanks!
paul

On Thu, Oct 23, 2014 at 10:22 AM, Michael Hanke m...@debian.org wrote:

 Hi,

 On Tue, Oct 21, 2014 at 08:42:50AM -0400, Paul Yushkevich wrote:
  That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to
  /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I
 am
  not quite sure why the VTK and GDCM are becoming an issue in the debian
  build, perhaps ITK and VTK are configured slightly differently from the
 way
  I have them configured.

 I tried building today's dev32 branch, but the QT plugin issue remains.

 CMake Error at CMakeLists.txt:1135 (get_property):
   get_property could not find TARGET Qt5::QXcbIntegrationPlugin.  Perhaps
 it
   has not yet been created.
 CMake Error at CMakeLists.txt:1136 (get_property):
   get_property could not find TARGET Qt5::QGifPlugin.  Perhaps it has not
 yet
   been created.

 I do have the relevant package installed and the plugins are present:

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
 /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so

 Any idea what needs to be done to help cmake find them?

 Michael




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

I am not quite sure where on the Debian system Qt cmake files are, but I
think you should be able to find them using

locate Qt5Config.cmake

Thanks!
Paul

On Thu, Oct 23, 2014 at 10:43 AM, Paul Yushkevich pau...@mail.med.upenn.edu
 wrote:

 Hi Michael,

 Please try setting the CMAKE_PREFIX_PATH to
 [PATH_TO_QT_INSTALLATION]/lib/cmake

 In my case that's /opt/Qt/5.3/gcc_64/lib/cmake

 This can be provided to Cmake with the -D command, or set in the
 environment.

 Please let me know if that helps

 Thanks!
 paul

 On Thu, Oct 23, 2014 at 10:22 AM, Michael Hanke m...@debian.org wrote:

 Hi,

 On Tue, Oct 21, 2014 at 08:42:50AM -0400, Paul Yushkevich wrote:
  That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to
  /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I
 am
  not quite sure why the VTK and GDCM are becoming an issue in the debian
  build, perhaps ITK and VTK are configured slightly differently from the
 way
  I have them configured.

 I tried building today's dev32 branch, but the QT plugin issue remains.

 CMake Error at CMakeLists.txt:1135 (get_property):
   get_property could not find TARGET Qt5::QXcbIntegrationPlugin.  Perhaps
 it
   has not yet been created.
 CMake Error at CMakeLists.txt:1136 (get_property):
   get_property could not find TARGET Qt5::QGifPlugin.  Perhaps it has not
 yet
   been created.

 I do have the relevant package installed and the plugins are present:

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
 /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so

 Any idea what needs to be done to help cmake find them?

 Michael




 --
 Paul A. Yushkevich, Ph.D.
 Associate Professor
 Penn Image Computing and Science Laboratory
 Department of Radiology
 University of Pennsylvania




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Michael

Please try cmake ... -D CMAKE_PREFIX_PATH:STRING=/usr/lib/
x86_64-linux-gnu/cmake

And let me know if that works any better.

Thanks!
Paul

On Thu, Oct 23, 2014 at 10:50 AM, Michael Hanke m...@debian.org wrote:

 On Thu, Oct 23, 2014 at 10:43:56AM -0400, Paul Yushkevich wrote:
  I am not quite sure where on the Debian system Qt cmake files are, but I
  think you should be able to find them using
 
  locate Qt5Config.cmake

 The file is here:

 /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake

  On Thu, Oct 23, 2014 at 10:43 AM, Paul Yushkevich 
 pau...@mail.med.upenn.edu
   Please try setting the CMAKE_PREFIX_PATH to
   [PATH_TO_QT_INSTALLATION]/lib/cmake
  
   In my case that's /opt/Qt/5.3/gcc_64/lib/cmake

 I tried

   cmake .. -DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5

 and a bunch of other variants, but the problem persists.

 Michael


 --
 Michael Hanke
 http://mih.voxindeserto.de




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Hi Michael,

I am confused :)

You previously mentioned that the file
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
exists on the system

I was suggesting to set the prefix path to /usr/lib/x86_64-linux-gnu/cmake
- so that directory should exist

I am happy to add a CMake flag that will disable the search for the
plugins. We need the plugins when packaging ITK-SNAP binaries using make
package. Otherwise if a system does not already have Qt installed, the user
is hosed.

Thanks!
Paul



On Thu, Oct 23, 2014 at 11:40 AM, Michael Hanke m...@debian.org wrote:

 On Thu, Oct 23, 2014 at 11:26:50AM -0400, Paul Yushkevich wrote:
  Please try cmake ... -D CMAKE_PREFIX_PATH:STRING=/usr/lib/
  x86_64-linux-gnu/cmake
 
  And let me know if that works any better.

 No, it doesn't -- such a directory doesn't exist.

 I believe the CMake setup assumes a rigidity of a Qt5 installation that
 does not match the actual installation of the Debian (Ubuntu, Mint,...)
 system
 Qt5.

 Michael



 --
 Michael Hanke
 http://mih.voxindeserto.de




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Oh... Weird. Could you try without the space after -D?

Thanks!

On Thu, Oct 23, 2014 at 12:05 PM, Michael Hanke m...@debian.org wrote:

 Hi,

 On Thu, Oct 23, 2014 at 11:57:19AM -0400, Paul Yushkevich wrote:
  Hi Michael,
 
  I am confused :)
 
  You previously mentioned that the file
  /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
  exists on the system
 
  I was suggesting to set the prefix path to
 /usr/lib/x86_64-linux-gnu/cmake
  - so that directory should exist

 Sorry, I was sloppy. The directory exists, but it doesn't have cmake
 files:

 % cmake .. -D CMAKE_PREFIX_PATH:STRING=/usr/lib/x86_64-linux-gnu/cmake
 CMake Error: The source directory /usr/lib/x86_64-linux-gnu/cmake does
 not appear to contain CMakeLists.txt.
 Specify --help for usage, or press the help button on the CMake GUI.

 % ll /usr/lib/x86_64-linux-gnu/cmake
 total 72K
 drwxr-xr-x 2 root root 4,0K Okt 12 10:06 PulseAudio/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Concurrent/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Core/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5DBus/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Gui/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Network/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGL/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGLExtensions/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5PrintSupport/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Qml/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Quick/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickTest/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickWidgets/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Sql/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Test/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Widgets/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Xml/

  I am happy to add a CMake flag that will disable the search for the
  plugins. We need the plugins when packaging ITK-SNAP binaries using make
  package. Otherwise if a system does not already have Qt installed, the
 user
  is hosed.

 That would be good. For the Debian package we can specify any runtime
 dependencies in the binary package (if they aren't already explicit from
 the linker output). It sounds like that would fulfil all requirements of
 itksnap.


 Michael




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

I just pushed a commit in the dev32 branch that includes a CMAKE
flag SNAP_PACKAGE_QT_PLUGINS. Setting this to off should disable the search
for plugins.

Thanks!
Paul

On Thu, Oct 23, 2014 at 12:27 PM, Paul Yushkevich pau...@mail.med.upenn.edu
 wrote:

 Oh... Weird. Could you try without the space after -D?

 Thanks!

 On Thu, Oct 23, 2014 at 12:05 PM, Michael Hanke m...@debian.org wrote:

 Hi,

 On Thu, Oct 23, 2014 at 11:57:19AM -0400, Paul Yushkevich wrote:
  Hi Michael,
 
  I am confused :)
 
  You previously mentioned that the file
  /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
  exists on the system
 
  I was suggesting to set the prefix path to
 /usr/lib/x86_64-linux-gnu/cmake
  - so that directory should exist

 Sorry, I was sloppy. The directory exists, but it doesn't have cmake
 files:

 % cmake .. -D CMAKE_PREFIX_PATH:STRING=/usr/lib/x86_64-linux-gnu/cmake
 CMake Error: The source directory /usr/lib/x86_64-linux-gnu/cmake does
 not appear to contain CMakeLists.txt.
 Specify --help for usage, or press the help button on the CMake GUI.

 % ll /usr/lib/x86_64-linux-gnu/cmake
 total 72K
 drwxr-xr-x 2 root root 4,0K Okt 12 10:06 PulseAudio/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Concurrent/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Core/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5DBus/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Gui/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Network/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGL/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGLExtensions/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5PrintSupport/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Qml/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Quick/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickTest/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickWidgets/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Sql/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Test/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Widgets/
 drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Xml/

  I am happy to add a CMake flag that will disable the search for the
  plugins. We need the plugins when packaging ITK-SNAP binaries using make
  package. Otherwise if a system does not already have Qt installed, the
 user
  is hosed.

 That would be good. For the Debian package we can specify any runtime
 dependencies in the binary package (if they aren't already explicit from
 the linker output). It sounds like that would fulfil all requirements of
 itksnap.


 Michael




 --
 Paul A. Yushkevich, Ph.D.
 Associate Professor
 Penn Image Computing and Science Laboratory
 Department of Radiology
 University of Pennsylvania




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Hi Gert,

I am going to try looking into this problem this week. I have been building
on Centos, and there the Qt plugins are being picked up just fine. I
suspect the crash is due to the missing plugin, but I am not sure.

Could you tell me why including all VTK libs and GDCM libs was required?

Thanks!
Paul

On Thu, Oct 16, 2014 at 7:33 AM, Gert Wollny gw.foss...@gmail.com wrote:

 Hello Paul,

 in Debian we are currently at ITK 4.6 and VTK 6.1 and AFAICS this is
 what will go into Jessie. Hence, if you could get a version released
 that can be compiled with these two libraries, we could update it,
 Note however, that the freeze for Jessie is only a few weeks away.


  Here is a table of version compatibility between versions of ITK-SNAP,
 ITK,
  VTK and Qt.
 
 http://www.itksnap.org/pmwiki/pmwiki.php?n=Documentation.BuildingITK-SNAP.

 With the latest dev32 branch I get

  get_property could not find TARGET Qt5::QXcbIntegrationPlugin.
   Perhaps it has not yet been created.


 CMake Error at CMakeLists.txt:1134 (get_property):
   get_property could not find TARGET Qt5::QGifPlugin.  Perhaps it has
   not yet been created.

 and I just don't know whether this is a problem with itksnap not
 properly searching or because the QT5 packages (5.3) don't include
 these plugins for some reason. I  have
   /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so
 and
   /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so

 --

 Well, after some fiddling I got the attached patch that makes it build.

 This patch does the following:

 * revert dd5b67 (this is where above plug-ins are searched for)
 * Add a Find_package for gdcm and gdcmCommon to the link_libraries.
 * Use all vtk libraries

 With this the software as of commit 32eaf0+patch builds with the warning
 about libjpeg.so.62 and libjpeg.so.8 being pulled in at the same time
 (The first is  the fault of libtiff  and should go away when a new
 libtiff gets build against libjpeg.so.8 )

 The resulting executable segfaults though:

 ./ITK-SNAP(_Z24SegmentationFaultHandleri+0x7b)[0x74b25b]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f60494958d0]
 /lib/x86_64-linux-gnu/libc.so.6(strlen+0x2a)[0x7f60272d4a3a]

 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication9argumentsEv+0xb1)[0x7f6027df4b41]

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x3260f)[0x7f600caa160f]

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x32923)[0x7f600caa1923]

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x40f3c)[0x7f600caaff3c]

 /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x32061)[0x7f600caa1061]
 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5(_ZN14QWindowPrivate6createEb
 +0x66)[0x7f602833a4b6]

 /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN10QGLContext13chooseContextEPKS_+0x133)[0x7f6029481423]
 /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN10QGLContext6createEPKS_
 +0x26)[0x7f6029459c36]

 /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN9QGLWidget10setContextEP10QGLContextPKS0_b+0xaf)[0x7f6029480e8f]

 /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN16QGLWidgetPrivate11initContextEP10QGLContextPK9QGLWidget+0x7f)[0x7f602945e1cf]

 /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN9QGLWidgetC2EP7QWidgetPKS_6QFlagsIN2Qt10WindowTypeEE+0x10a)[0x7f602945df2a]
 ./ITK-SNAP(_ZN19QtAbstractOpenGLBoxC1EP7QWidget+0xd)[0x7fa46d]
 ./ITK-SNAP(_ZN16GenericSliceViewC2EP7QWidget+0x12)[0x7f4212]
 ./ITK-SNAP(_ZN17Ui_SliceViewPanel7setupUiEP7QWidget+0x2154)[0x7ed1f4]
 ./ITK-SNAP(_ZN14SliceViewPanelC1EP7QWidget+0x55)[0x7e6ad5]
 ./ITK-SNAP(_ZN18Ui_MainImageWindow7setupUiEP11QMainWindow
 +0x250b)[0x781c6b]
 ./ITK-SNAP(_ZN15MainImageWindowC2EP7QWidget+0x64)[0x772f24]
 ./ITK-SNAP(main+0x1c0)[0x744f00]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6027274b45]
 ./ITK-SNAP[0x74b0f7]



 Best
 Gert




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Thanks, Gert,

A quick question about the plugins: when you build with Cmake, did you have
CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think
this is the way the plugins get picked up.

I've set up a VM with Debian and am trying to build everything now.

Paul

On Tue, Oct 21, 2014 at 6:19 AM, Gert Wollny gw.foss...@gmail.com wrote:

 Hello Paul,



 On Tue, 2014-10-21 at 04:45 -0400, Paul Yushkevich wrote:
  I am going to try looking into this problem this week. I have been
 building
  on Centos, and there the Qt plugins are being picked up just fine. I
  suspect the crash is due to the missing plugin, but I am not sure.
 The crash is within

  QCoreApplication::arguments ()

 and it doesn't seem to crash reliable. Somehow I suspect that there is a
 mixup in symbols resolution, i.e. I added code like:

   char *a = lala;
   SNAPQApplication app(1, a);
   QStringList mylist = app.arguments();

 and it crashes in this very call to app.arguments() without going
 through the plug-in loading. I also call arguments() in the
 SNAPQApplication() constructor to check it and there it doesn't cash.

 When I use valgrind*, then it reports jump depends on un-initialized
 values within the final loop of  QCoreApplication::arguments (), but
 only outside the constructor.

 I can only guess that the upload of QT5 that came after the upload of
 libvtk6-dev which depends on QT5 broke something and a binary upload of
 vtk could help.

  Could you tell me why including all VTK libs and GDCM libs was required?
 I think not all VTK libs are required, but some symbols where missing,
 and it was easier to add all libraries instead of finding out what is
 really needed. There was also a symbol missing from GDCM.

 Note, that I worked with the dev32 branch.

 Best
 Gert

 * valgrind reports a number of problems with the code. For some of them
 I sent patches upstream, see
  https://sourceforge.net/p/itk-snap/bugs/81/
  https://sourceforge.net/p/itk-snap/bugs/82/






-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

I'm getting the same error in QCoreApplication... Oddly, this happens in
Debian but not other OSs.

Hope I can find a fix :)

On Tue, Oct 21, 2014 at 6:38 AM, Gert Wollny gw.foss...@gmail.com wrote:

 On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote:
  A quick question about the plugins: when you build with Cmake, did you
 have
  CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think
  this is the way the plugins get picked up.

 No, I didn't.





-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Ok - it was an easy fix. I just checked it into dev32. Gert - could you
please confirm that the code runs and builds now?

Thanks!
Paul

On Tue, Oct 21, 2014 at 6:58 AM, Paul Yushkevich pau...@mail.med.upenn.edu
wrote:

 I'm getting the same error in QCoreApplication... Oddly, this happens in
 Debian but not other OSs.

 Hope I can find a fix :)

 On Tue, Oct 21, 2014 at 6:38 AM, Gert Wollny gw.foss...@gmail.com wrote:

 On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote:
  A quick question about the plugins: when you build with Cmake, did you
 have
  CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think
  this is the way the plugins get picked up.

 No, I didn't.





 --
 Paul A. Yushkevich, Ph.D.
 Associate Professor
 Penn Image Computing and Science Laboratory
 Department of Radiology
 University of Pennsylvania




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Hi Gert,

That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to
/opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I am
not quite sure why the VTK and GDCM are becoming an issue in the debian
build, perhaps ITK and VTK are configured slightly differently from the way
I have them configured.

I am going to bump the version to 3.2.0 today or tomorrow (making it an
official release). It would be great if we could get this version into
Debian instead of 3.2.0-rc2

Thanks!
Paul



On Tue, Oct 21, 2014 at 8:28 AM, Gert Wollny gw.foss...@gmail.com wrote:

 On Tue, 2014-10-21 at 07:49 -0400, Paul Yushkevich wrote:
  Ok - it was an easy fix. I just checked it into dev32. Gert - could you
  please confirm that the code runs and builds now?

 Okay, when I can build it with the patches applied (disabling the search
 for the plug-ins with cmake and added VTK/GDCM libraries). Then the
 executable now starts properly, and I can load images and segmentation
 etc. Looks great :)

 thanks
 Gert




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania

Bug#698386: Is there a future for ITKSNAP?

[Paul Yushkevich]

Hi Michael

Sorry that this is causing so much frustration. Unfortunately, ITK and VTK
keep changing fairly rapidly, so code that compiles versus a certain
version no longer compiles against older or later versions.

Here is a table of version compatibility between versions of ITK-SNAP, ITK,
VTK and Qt.
http://www.itksnap.org/pmwiki/pmwiki.php?n=Documentation.BuildingITK-SNAP.

Does this help?

Thanks
Paul

On Wed, Oct 15, 2014 at 1:00 PM, Michael Hanke m...@debian.org wrote:

 Hi,

 I am reviving this old thread in order to bring it to an end. Everyone
 who has expressed interest and/or frustration in the past is in CC
 (incl. the relevant bug).

 Over the past month (or rather year) I have repeatedly tried to update
 the itksnap package, and today I am giving up. ITK-SNAP has extremely
 tight versioned dependencies on ITK and VTK. Making it work with any
 current ITK version in Debian seems to require a lucky roll of the dice
 (that would not come for me). As of today, neither the current stable
 3.2, nor the master branch head compiles in sid. At least for the first
 I am pretty sure a version mismatch is the case (see e.g. [1]).
 The actual reasons for FTBFS change over time, but the failure rate is
 close to 100% for my attempts.

 My personal conclusion is that it makes no sense to maintain an itksnap
 package independently of ITK.

 The package has a popcon score of 241 -- rather solid for a special
 interest package of this kind (about half of what ITK3 had in its
 prime). It would be a shame to see it go away. On the other hand
 dragging an outdated version along forever is not an option.

 And to make it very clear: ITK-SNAP is a solid piece of software that I
 have enjoyed using (and still do). The problem is solely a ridiculously
 complex software interdependency problem, that makes long-term package
 maintenance a nightmare.

 I have tagged the bug with help. I see no reason to remove itksnap
 from jessie, because this old version does what it was intended to do.
 But for the next round we either need to find a better home, or we
 should let it go.

 Cheers,

 Michael

 [1] https://groups.google.com/forum/#!topic/itksnap-users/2byPxMTS3Wo



 --
 Michael Hanke
 http://mih.voxindeserto.de




-- 
Paul A. Yushkevich, Ph.D.
Associate Professor
Penn Image Computing and Science Laboratory
Department of Radiology
University of Pennsylvania