I want to use the InsightToolKit ITK from http://www.itk.org/ . The site has an ebuild available, but I cannot find it in portage (there is an dev-tcltk/itk in portage, but this is something else). Why isn't this ebuild added to portage? Links: http://www.elreki.net/gentoo/itk-2.4.1.ebuild http://www.itk.org/Wiki/ITK_Configuring_and_Building
Created attachment 80826 [details] itk 2.4.1 ebuild
I have found a problem building ITK on an em64t system with gcc-4.1. This failed: Building CXX object Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/Templates/vnl_det+vnl_rational-.o Building CXX object Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/Templates/vnl_vector_fixed_ref+double.3-.o Building CXX object Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/Templates/vnl_complex_ops+float-.o /var/tmp/portage/itk-2.4.1/work/InsightToolkit-2-4-1/Utilities/vxl/core/vnl/vnl_vector_fixed_ref.h: In member function 'const vnl_vector_fixed_ref<T, n>& vnl_vector_fixed_ref<T, n>::operator/=(T) const [with T = double, unsigned int n = 3u]': /var/tmp/portage/itk-2.4.1/work/InsightToolkit-2-4-1/Utilities/vxl/core/vnl/Templates/vnl_vector_fixed_ref+double.3-.cxx:2: instantiated from here /var/tmp/portage/itk-2.4.1/work/InsightToolkit-2-4-1/Utilities/vxl/core/vnl/vnl_vector_fixed_ref.h:384: error: invalid conversion from 'double*' to 'int' /var/tmp/portage/itk-2.4.1/work/InsightToolkit-2-4-1/Utilities/vxl/core/vnl/vnl_vector_fixed_ref.h:384: warning: converting to 'int' from 'double' /usr/include/gentoo-multilib/amd64/stdlib.h:801: error: too many arguments to function 'div_t div(int, int)' /var/tmp/portage/itk-2.4.1/work/InsightToolkit-2-4-1/Utilities/vxl/core/vnl/vnl_vector_fixed_ref.h:384: error: at this point in file make[2]: *** [Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/Templates/vnl_vector_fixed_ref+double.3-.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [Utilities/vxl/core/vnl/CMakeFiles/itkvnl.dir/all] Error 2 make: *** [all] Error 2 It works with gcc-4.0.2 on i386 and with gcc-3.4.4 on EM64T.
Hi Sebastiaan, Thanks for the ebuild! This looks like an interesting package and I'll have a closer look at it soon. Thanks, Markus
Ok, I have been able to solve the problem. It compiles with gcc-4.0.2, but not with 4.1. The problem is that a member fuction 'div' is called, but the compiler uses the gcc divide function. I have no idea if this is due to a bad implementation of ITK, or if there is something seriously wrong with gcc-4.1. Anyway, here is a patch and a new ebuild. I am not sure if this patches the problem properly, so it is only applied if gcc==4.1.
Created attachment 82763 [details] itk-2.4.1-r1.ebuild
Created attachment 82764 [details, diff] itk-2.4.1-gcc4.1.patch
*** Bug 134094 has been marked as a duplicate of this bug. ***
Created attachment 87317 [details] itk-2.6.0.ebuild
Created attachment 87318 [details] itk-2.6.0-gcc4.1.patch
Created attachment 87319 [details] itk-applications-2.6.0.ebuild
Added new ebuilds for 2.6.0 version with gcc patch. Also made an ebuild for the ITK-applications, although this package still puzzles me about the proper integretion on the system...
Created attachment 97665 [details] sci-libs/itk-2.8.1.ebuild New ebuild for Insight Segmentation Toolkit v2.8.1. This ebuild includes support for the "test" USE flag to run extensive tests over the toolkit. The 2.8.1 ebuild has been tested on amd64 using gcc-4.1.1 and does not require the original source to be patched on this platform/architecture combination. Please integrate the sci-libs/itk ebuild into the standard portage tree.
Noticed that this bug report doesn't contain a description of itk for the manifest file. I would suggest that itk be placed in the sci-libs category in portage. Please find an appropriate description below: The Insight Segmentation and Registration Toolkit (ITK) is an open-source software system developed by the National Library of Medicine to support the Visible Human Project (http://www.nlm.nih.gov/research/visible/visible_human.html). Currently under active development, ITK employs leading-edge segmentation and registration algorithms in two, three and more dimensions.
Created attachment 107965 [details] itk-3.0.1.ebuild new ebuild for the 3.0.1 release. After installation, you have to exchange a line in the /usr/lib/InsightToolkit/ITKConfig.cmake file: exchange that: SET(ITK_INCLUDE_DIRS "/usr/include/InsightToolkit;/usr/include/InsightToolkit/Algorithms;/usr/include/InsightToolkit/BasicFilters;/usr/include/InsightToolkit/Common;/usr/include/InsightToolkit/expat;/usr/include/InsightToolkit/Numerics;/usr/include/InsightToolkit/IO;/usr/include/InsightToolkit/Numerics/FEM;/usr/include/InsightToolkit/Numerics/Statistics;/usr/include/InsightToolkit/Numerics/NeuralNetworks;/usr/include/InsightToolkit/SpatialObject;/usr/include/InsightToolkit/Utilities/MetaIO;/usr/include/InsightToolkit/Utilities/NrrdIO;/usr/include/InsightToolkit/Utilities/DICOMParser;/usr/include/InsightToolkit/Utilities/itkExtHdrs;/usr/include/InsightToolkit/Utilities;/usr/include/InsightToolkit/Utilities/vxl/vcl;/usr/include/InsightToolkit/Utilities/vxl/core;/var/tmp/portage/itk-3.0.1/work/InsightToolkit-3.0.1/Utilities/gdcm;/var/tmp/portage/itk-3.0.1/work/InsightToolkit-3.0.1/Utilities/gdcm/src;/usr/include/InsightToolkit/Patented;/usr/include;/usr/include;/usr/include") with this line: SET(ITK_INCLUDE_DIRS "/usr/include/InsightToolkit;/usr/include/InsightToolkit/Algorithms;/usr/include/InsightToolkit/BasicFilters;/usr/include/InsightToolkit/Common;/usr/include/InsightToolkit/expat;/usr/include/InsightToolkit/Numerics;/usr/include/InsightToolkit/IO;/usr/include/InsightToolkit/Numerics/FEM;/usr/include/InsightToolkit/Numerics/Statistics;/usr/include/InsightToolkit/Numerics/NeuralNetworks;/usr/include/InsightToolkit/SpatialObject;/usr/include/InsightToolkit/Utilities/MetaIO;/usr/include/InsightToolkit/Utilities/NrrdIO;/usr/include/InsightToolkit/Utilities/DICOMParser;/usr/include/InsightToolkit/Utilities/itkExtHdrs;/usr/include/InsightToolkit/Utilities;/usr/include/InsightToolkit/Utilities/vxl/vcl;/usr/include/InsightToolkit/Utilities/vxl/core;/usr/include/InsightToolkit/gdcm;/usr/include/InsightToolkit/gdcm/src;/usr/include/InsightToolkit/Patented;/usr/include;/usr/include;/usr/include") otherwise cmake-based programs relying on ITK will not compile correctly. the proper solution would be to edit CMakeLists.txt and itkIncludeDirectories.cmake in the source dir accordingly. but this is an upstream bug, IMHO.
Thanks for this ebuild. It also works with 3.2 version. I just renamed the file.
the ebuild works also for 3.4.0
Works also for the version 3.6.0.
(In reply to comment #17) > Works also for the version 3.6.0. > Works also for version 3.12.0
Created attachment 195970 [details] Ebuild for the latest version 3.14.0 This ebuild adds support for fftw and the creation of python bindings. If you enable python you will need CableSwig (see Bug 275717)
Created attachment 195972 [details] The metadata file for the local use flags.
Tested with a bump to 3.16.0. Build works, and python bindings are generated, but they are stored in /usr/lib/InsightToolkit/python, which makes them difficult to import. According to Gentoo Python convention, the bindings should be written to /usr/lib/python(ver)/site-packages/
Created attachment 215558 [details] ebuild for itk 3.16 I spoke to some ITK developers yesterday. I came away with the impression that the old python bindings are basically abandoned, and all new work should use the WrapITK bindings, which have been included into the main ITK tarballs. This ebuild has useflags to choose between bindings.
Created attachment 215560 [details] use flag labels for itk-3.16.0.ebuild This metadata.xml includes use flag labels for new flags "numpy" and "oldpython" that are used in itk-3.16.0.ebuild.
Created attachment 215874 [details] ebuild for itk 3.16 Improved ebuild for itk 3.16. I have split the numpy support into another ebuild, which is better because it actually works.
Created attachment 215876 [details] ebuild for itk-numpy 3.16 This ebuild contains the semi-independent WrapITK Numpy bindings (a.k.a. PyBuffer). It requires a patch to compile.
Created attachment 215877 [details, diff] Patch to fix compilation of Numpy bindings Patch to enable numpy bindings to actually compile.
Hi all, I would be ready to put this one in portage if anyone is interested in proxy-maintaining it. The ebuilds need some work however: * needs to use the cmake_utils eclass (see plplot ebuild for ex) * use emake install * don't use dodoc for html docs, use either dohtml or insinto and doins * remove cruft (the src_unpack is useless so are the cd "${S}"). Thanks
Any plans to add the ebuilds to portage soon? This tool is the swiss knife in image processing in medicine and it's more than needed.
(In reply to comment #28) > Any plans to add the ebuilds to portage soon? > > This tool is the swiss knife in image processing in medicine and it's more than > needed. > You could try to fix the ebuild up. Sebastien already voluntered to proxy it to the tree.
Thank you for the new ebuilds. I have 3 issues (1 unsolved): 1) compiling itk it with gcc>=4.3.4 gives problems: [ 35%] Generating wrap_vcl_complex.xml In file included from /usr/include/wchar.h:882, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/cwchar:47, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/bits/postypes.h:42, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/iosfwd:42, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/ios:39, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/istream:40, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/sstream:39, from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/complex:47, from /var/tmp/portage/sci-libs/itk-3.16.0-r1/work/InsightToolkit-3.16.0/Utilities/vxl/vcl/iso/vcl_complex.h:6, from /var/tmp/portage/sci-libs/itk-3.16.0-r1/work/InsightToolkit-3.16.0/Utilities/vxl/vcl/vcl_complex.h:62, from /var/tmp/portage/sci-libs/itk-3.16.0-r1/work/InsightToolkit-3.16.0/Wrapping/WrapITK/Modules/VXLNumerics/wrap_vcl_complex.cxx:1: /usr/include/bits/wchar2.h: In function 'int swprintf(wchar_t*, size_t, const wchar_t*, ...)': /usr/include/bits/wchar2.h:290: error: '__builtin_va_arg_pack' was not declared in this scope /usr/include/bits/wchar2.h:291: error: '__builtin_va_arg_pack' was not declared in this scope /usr/include/bits/wchar2.h: In function 'int wprintf(const wchar_t*, ...)': /usr/include/bits/wchar2.h:340: error: '__builtin_va_arg_pack' was not declared in this scope /usr/include/bits/wchar2.h: In function 'int fwprintf(__FILE*, const wchar_t*, ...)': /usr/include/bits/wchar2.h:347: error: '__builtin_va_arg_pack' was not declared in this scope make[2]: *** [Wrapping/WrapITK/Modules/VXLNumerics/wrap_vcl_complex.xml] Error 1 make[1]: *** [Wrapping/WrapITK/Modules/VXLNumerics/CMakeFiles/_VXLNumericsPython.dir/all] Error 2 make: *** [all] Error 2 gcc-4.2.4 works fine (for some reason, itk/vtk have a long history in failing to compile with new compilers - why is that?). 2) circular dependency of itk and itk-numpy: [nomerge ] sci-libs/itk-3.16.0-r1 [3.10.1] USE="doc* examples* fftw%* numpy%* patented python%* shared -oldpython% -test" [?=>1] [ebuild N ] sci-libs/itk-numpy-3.16.0 0 kB [1] [ebuild U ] sci-libs/itk-3.16.0-r1 [3.10.1] USE="doc* examples* fftw%* numpy%* patented python%* shared -oldpython% -test" 0 kB [?=>1] * Error: circular dependencies: ('ebuild', '/', 'sci-libs/itk-numpy-3.16.0', 'merge') depends on ('ebuild', '/', 'sci-libs/itk-3.16.0-r1', 'merge') (buildtime) ('ebuild', '/', 'sci-libs/itk-3.16.0-r1', 'merge') depends on ('ebuild', '/', 'sci-libs/itk-numpy-3.16.0', 'merge') (buildtime) Building itk with USE=-numpy works, but I am unable to find a good fix for the ebuilds. 3) building itk-numpy fails when linking: [100%] Building CXX object CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o /var/tmp/portage/sci-libs/itk-numpy-3.16.0/work/InsightToolkit-3.16.0/Wrapping/WrapITK/ExternalProjects/PyBuffer/wrap_itkPyBufferPython.cxx: In function 'PyObject* _wrap_itkPyBufferIF2_GetArrayFromImage(PyObject*, PyObject*)': (... long list of similar issues ...) /var/tmp/portage/sci-libs/itk-numpy-3.16.0/work/InsightToolkit-3.16.0/Wrapping/WrapITK/ExternalProjects/PyBuffer/itkPyBuffer.txx:64: error: cannot convert 'int*' to 'npy_intp*' in argument passing make[2]: *** [CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o] Error 1 make[1]: *** [CMakeFiles/_BufferConversionPython.dir/all] Error 2 make: *** [all] Error 2 I have not figured out how to fix this one. Thanks!
Created attachment 238059 [details, diff] Make itk compile with libpng-1.4
Created attachment 238063 [details] New ebuild for version 3.18.0 This ebuild adds use flags for various build options. If you want to build itk with python support you will also need an ebuild for cableswig. see bug #275717
Created attachment 238065 [details] Ubdated use flag description
Created attachment 238069 [details] update actually based on the 3.16.0 ebuild
Created attachment 238071 [details] Add the oldpython use flag I ommited the numpy use flag because it is not actually used by this ebuild.
Created attachment 238085 [details] yet another update
Created attachment 238087 [details] Make better use of cmake-utils and set proper EAPI
Comment on attachment 238087 [details] Make better use of cmake-utils and set proper EAPI The ebuild needs some more testing.
Created attachment 238157 [details] Ebuild using cmake-utils that actually works * added xml use flag * For the moment the doc useflag is disabled. It would probably be better to create a seperate ebuild that downloads the pre-build documentation.
Ah, finally got itk to compile successfully with the latest ebuild! However, I had to downgrade libtiff to 3.9.4 from 4.0.0_beta6, which we require for its BigTIFF support. So itk fails to compile with the latest version of media-libs/tiff with the following error: [ 95%] [ 95%] Building CXX object Code/IO/CMakeFiles/ITKIO.dir/itkTransformFileReader.o Building CXX object Code/IO/CMakeFiles/ITKIO.dir/itkTransformFileWriter.o /var/tmp/portage/sci-libs/itk-3.18.0/work/InsightToolkit-3.18.0/Code/IO/itkTIFFImageIO.cxx: In member function 'bool itk::TIFFImageIO::CanFindTIFFTag(unsigned int)': /var/tmp/portage/sci-libs/itk-3.18.0/work/InsightToolkit-3.18.0/Code/IO/itkTIFFImageIO.cxx:1869: error: cannot convert 'const TIFFField*' to 'const TIFFFieldInfo*' in initialization /var/tmp/portage/sci-libs/itk-3.18.0/work/InsightToolkit-3.18.0/Code/IO/itkTIFFImageIO.cxx: In member function 'void* itk::TIFFImageIO::ReadRawByteFromTag(unsigned int, short int&)': /var/tmp/portage/sci-libs/itk-3.18.0/work/InsightToolkit-3.18.0/Code/IO/itkTIFFImageIO.cxx:1887: error: cannot convert 'const TIFFField*' to 'const TIFFFieldInfo*' in initialization make[2]: *** [Code/IO/CMakeFiles/ITKIO.dir/itkTIFFImageIO.o] Error 1 make[1]: *** [Code/IO/CMakeFiles/ITKIO.dir/all] Error 2 make: *** [all] Error 2 * ERROR: sci-libs/itk-3.18.0 failed:
Hello all, I tried to digest the ebuild (3.18, comment #39), and got this message: !!! missing space by parenthesis: '(m' I'm new to ebuild digest and so, so maybe it is a very simple solution. I'm in a amd64, and using Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.11.2-r0, 2.6.31-gentoo-r10 x86_64). Any hint? Thanks, Eliana
(In reply to comment #41) > Hello all, > I tried to digest the ebuild (3.18, comment #39), and got this message: > > !!! missing space by parenthesis: '(m' > > I'm new to ebuild digest and so, so maybe it is a very simple solution. > > I'm in a amd64, and using Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, > glibc-2.11.2-r0, 2.6.31-gentoo-r10 x86_64). > Could not reproduce your problem here, but my set up is very different. Did you use "ebuild itk-3.18.ebuild manifest" or digest? digest is obsolete, it shouldn't cause problem but we never know.
(In reply to comment #42) > (In reply to comment #41) > > Hello all, > > I tried to digest the ebuild (3.18, comment #39), and got this message: > > > > !!! missing space by parenthesis: '(m' > > > > I'm new to ebuild digest and so, so maybe it is a very simple solution. > > > > I'm in a amd64, and using Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, > > glibc-2.11.2-r0, 2.6.31-gentoo-r10 x86_64). > > > Could not reproduce your problem here, but my set up is very different. > Did you use "ebuild itk-3.18.ebuild manifest" or digest? digest is obsolete, > it shouldn't cause problem but we never know. > Originally I used digest. But running 'ebuild ... manifest' produces the same error message. Thanks for the info. Francois. :) Any other idea?
(In reply to comment #43) > (In reply to comment #42) > > (In reply to comment #41) > > > Hello all, > > > I tried to digest the ebuild (3.18, comment #39), and got this message: > > > > > > !!! missing space by parenthesis: '(m' > > > > > > I'm new to ebuild digest and so, so maybe it is a very simple solution. > > > > > > I'm in a amd64, and using Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, > > > glibc-2.11.2-r0, 2.6.31-gentoo-r10 x86_64). > > > > > Could not reproduce your problem here, but my set up is very different. > > Did you use "ebuild itk-3.18.ebuild manifest" or digest? digest is obsolete, > > it shouldn't cause problem but we never know. > > > > Originally I used digest. But running 'ebuild ... manifest' produces the same > error message. Thanks for the info. Francois. :) > > Any other idea? There is no lines with "(m" in the ebuild so I'd say it is something coming from an eclass or possibly something your version of portage cannot cope with. I will upload a slightly cleaned version of the ebuild shortly for you to try. I have noticed that one of the dependency of itk isn't in the main tree, the science overlay or the sunrise overlay: dev-utils/cableswig if there is a bug for it, it should block this one.
Created attachment 245697 [details] cleaned itk-3.18.0 ebuild I cannot make the previous ebuild obsolete as I lack authority to do so.
Created attachment 249783 [details] Version bump Version bump to 3.20.0
Created attachment 249784 [details] Version bump Version bump to 3.20.0
Is there anyone who has compiled itk-numpy succesfully on amd64? I am still having problems compiling itk-numpy. Hoping that the latest 3.20.0 version would work, I bumped the 3.18.0 ebuilds (with trivial updates). ITK compiles well: sci-libs/itk-3.20.0 USE="doc examples fftw patented python review shared xml -debug -oldpython -optreg -test" Unfortunately, itk-numpy still breaks with the same errors as before: [100%] Building CXX object CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o /var/tmp/portage/sci-libs/itk-numpy-3.16.0/work/InsightToolkit-3.16.0/Wrapping/WrapITK/ExternalProjects/PyBuffer/wrap_itkPyBufferPython.cxx: In function 'PyObject* _wrap_itkPyBufferIF2_GetArrayFromImage(PyObject*, PyObject*)': (... long list of similar issues ...) /var/tmp/portage/sci-libs/itk-numpy-3.16.0/work/InsightToolkit-3.16.0/Wrapping/WrapITK/ExternalProjects/PyBuffer/itkPyBuffer.txx:64: error: cannot convert 'int*' to 'npy_intp*' in argument passing make[2]: *** [CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o] Error 1 make[1]: *** [CMakeFiles/_BufferConversionPython.dir/all] Error 2 make: *** [all] Error 2 I am using gcc-4.4.4. Downgrading gcc to 4.2.4 did not help. I have also tried to compile itk with the 'oldpython' use-flag, but itk-numpy then fails with: CMake Error at CMakeLists.txt:2 (FIND_PACKAGE): Could not find module FindWrapITK.cmake or a configuration file for package WrapITK. Adjust CMAKE_MODULE_PATH to find FindWrapITK.cmake or set WrapITK_DIR to the directory containing a CMake configuration file for WrapITK. The file will have one of the following names: WrapITKConfig.cmake wrapitk-config.cmake CMake Error at CMakeLists.txt:10 (BEGIN_WRAPPER_LIBRARY): Unknown CMake command "BEGIN_WRAPPER_LIBRARY". CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.8) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PYTHON_NUMARRAY_INCLUDE_DIR used as include directory in directory /var/tmp/portage/sci-libs/itk-numpy-3.20.0/work/InsightToolkit-3.20.0/Wrapping/WrapITK/ExternalProjects/PyBuffer
(In reply to comment #48) > CMake Error at CMakeLists.txt:2 (FIND_PACKAGE): > Could not find module FindWrapITK.cmake or a configuration file for package > WrapITK. > > Adjust CMAKE_MODULE_PATH to find FindWrapITK.cmake or set WrapITK_DIR to > the directory containing a CMake configuration file for WrapITK. The file > will have one of the following names: > > WrapITKConfig.cmake > wrapitk-config.cmake > You should look for these from your itk installation and set the variable accordingly in the itk-numpy ebuild. > > CMake Error: The following variables are used in this project, but they are set > to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake > files: > PYTHON_NUMARRAY_INCLUDE_DIR > used as include directory in directory > /var/tmp/portage/sci-libs/itk-numpy-3.20.0/work/InsightToolkit-3.20.0/Wrapping/WrapITK/ExternalProjects/PyBuffer > Now that sucks. numarray is deprecated, out of the tree and won't come back. Given that numpy and numarray where originally competing and that one got killed so only one would be left (IIRC) you shouldn't use numpy and numarray simultaneously anyway. I may have a quick look at the build system later.
Thanks! I started researching this thing further, and it seems that WrapITKConfig.cmake is not generated when USE=+oldpython (since the whole WrapITK is not compiled). Since npy_int is nowhere defined in ITK, it seems that this may be more a python problem. I am using python 2.6 and numpy 1.5.0-r9. I tried python-3.1, but ITK does not compile with that. My installed versions are: [ebuild R ] sci-libs/itk-3.20.0 USE="doc examples fftw patented python review shared xml -debug -oldpython -optreg -test" 0 kB [?=>1] [ebuild R ] dev-python/numpy-1.5.0-r1 USE="lapack -doc -test" 0 kB [?=>1] [ebuild R ] dev-lang/python-2.6.5-r3 USE="berkdb gdbm ipv6 ncurses readline ssl threads tk (wide-unicode) xml -build -doc -examples -sqlite -wininst" 0 kB [0]
Comment on attachment 238157 [details] Ebuild using cmake-utils that actually works Francois Bissey cleaned this version
Created attachment 251573 [details] More cleanup on ebuild This ebuild * adds the reviewstats use flag * removes the test for the debug flag and the setting of the build type, without this the cmake-util class takes care that the settings from make.conf are used. * bumps the required version of cableswig to 3.20.0 (I don't know if this is necessary though Pending issues: * the doc use flag is not honored (maybe another ebuild, installing the prepared doc-package would be better, could add a dependecy if the doc flag is set) * conflicting use flags should be resolved automatically instead of letting the ebuild die. * maybe oldpython could be dropped altogether, since the new wrapping method is stable on linux and supports parallel builds.
Created attachment 251575 [details] New metadata including new use flag
Created attachment 253725 [details] Ebuild with new patch Finally found a patch for the itk-numpy problem: http://www.polyatomic.org/2010/10/28/doing-the-obvious/ Compiles smoothly now :)
Created attachment 253727 [details, diff] Patch to convert int to npy_intp
Created attachment 265461 [details, diff] path for build with media-libs/tiff-4.0.0_beta6
Hello all, It seens that the new png library (libpng-1.5.6) breaks the compilation of itk-3.20: [ 39%] Building CXX object Code/IO/CMakeFiles/ITKIO.dir/itkPNGImageIOFactory.o /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: In function 'void itk::itkPNGWriteErrorFunction(png_struct*, const char*)': /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:34:20: error: invalid use of incomplete type 'struct png_struct' /usr/include/png.h:833:16: error: forward declaration of 'struct png_struct' /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: In member function 'virtual void itk::PNGImageIO::Read(void*)': /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:230:15: error: invalid use of incomplete type 'struct png_info' /usr/include/png.h:702:16: error: forward declaration of 'struct png_info' /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:232:38: error: invalid use of incomplete type 'struct png_info' /usr/include/png.h:702:16: error: forward declaration of 'struct png_info' /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: In member function 'void itk::PNGImageIO::WriteSlice(const std::string&, const void*)': /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:499:7: error: invalid use of incomplete type 'struct png_struct' /usr/include/png.h:833:16: error: forward declaration of 'struct png_struct' make[2]: *** [Code/IO/CMakeFiles/ITKIO.dir/itkPNGImageIO.o] Error 1 Has anyone compiled itk with the 1.5.6 version of libpng? Thanks for the info. Eliana
(In reply to comment #57) > Hello all, > It seens that the new png library (libpng-1.5.6) breaks the compilation of > itk-3.20: > > [ 39%] Building CXX object Code/IO/CMakeFiles/ITKIO.dir/itkPNGImageIOFactory.o > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: > In function 'void itk::itkPNGWriteErrorFunction(png_struct*, const char*)': > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:34:20: > error: invalid use of incomplete type 'struct png_struct' > /usr/include/png.h:833:16: error: forward declaration of 'struct png_struct' > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: > In member function 'virtual void itk::PNGImageIO::Read(void*)': > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:230:15: > error: invalid use of incomplete type 'struct png_info' > /usr/include/png.h:702:16: error: forward declaration of 'struct png_info' > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:232:38: > error: invalid use of incomplete type 'struct png_info' > /usr/include/png.h:702:16: error: forward declaration of 'struct png_info' > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx: > In member function 'void itk::PNGImageIO::WriteSlice(const std::string&, const > void*)': > /var/tmp/portage/sci-libs/itk-3.20.0/work/InsightToolkit-3.20.0/Code/IO/itkPNGImageIO.cxx:499:7: > error: invalid use of incomplete type 'struct png_struct' > /usr/include/png.h:833:16: error: forward declaration of 'struct png_struct' > make[2]: *** [Code/IO/CMakeFiles/ITKIO.dir/itkPNGImageIO.o] Error 1 > > > Has anyone compiled itk with the 1.5.6 version of libpng? > > Thanks for the info. Eliana Not me. May be we should try to move things to itk-4.0 rather than trying to patch 3.20. Do you have a specific requirement for 3.20?
Created attachment 298551 [details] sci-libs/itk-3.20.1.ebuild This is a new ebuild for the previous stable 3.20.1 release I used before 4.0.0 was released. It includes a patch for the itkPNGImageIO.cxx adapted from some pre-4.0.0 svn.
Created attachment 298553 [details, diff] Make itk compile with libpng-1.5
Created attachment 332670 [details] Ebuild for itk-4.3.0 This is an ebuild for the latest version itk-4.3.0. I did one test build on amd64 with use flags "review shared python fftw hdf5"
Note, that version 4.X no longer needs CableSwig to create language bindings.
Created attachment 350564 [details] New ebuild for version 4.4 The new ebuild sets the slot for itk-4 to "4" in case someone wants to install version 3.X and 4.X at the same time. It also needs a patch (see below) to correct an error in the v3 compatibility code.
Created attachment 350566 [details, diff] Correct variable vor now const return value of GetInpu(...) A patch to correct an error in the v3compatibility code.
Does someone like to add it to the sci overlay? Please send a pull request on github.
I think putting it into a slot other than "0" was also not a good idea, Some files are installed that don't carry version information (e.g. files related to python wrapping). As for the sci overlay, I'll do it some day during the week.
