[Dcmlib] Re: Probleme compil vtkGdcmReader RH9

Benoit Regrain benoit.regrain at creatis.insa-lyon.fr
Tue Nov 4 14:06:20 CET 2003


J'ai aussi le même problème, et il semble que ca vienne d'une variable de
vtk pour python...
pendant l'autogen, j'obtiens :

###################################################
   pythondir(User, where = alocal.m4:178) =
   {
      TRUE => @pythondir@
   }
gdcmPython/Makefile.am:11: invalid variable 'LIBS_VTK_PYTHON'

t'as ca aussi Emmanuel ?

Benoit

----- Original Message ----- 
From: "Emmanuel Olart" <olart at theralys.com>
To: "Mathieu Malaterre" <Mathieu.Malaterre at creatis.insa-lyon.fr>
Cc: <dcmlib at creatis.insa-lyon.fr>
Sent: Tuesday, November 04, 2003 1:43 PM
Subject: [Dcmlib] Re: Probleme compil vtkGdcmReader RH9


> g++ -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>  --infodir=/usr/share/info --enable-shared --enable-threads=posix
>  --disable-checking --with-system-zlib --enable-__cxa_atexit
>  --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
>
> J'ai fait le test en mettant tout sur une ligne ca casse toujours.
> En fait l'erreur indiquee est a la ligne precedente : 242 :
>
> vtkErrorMacro("                      " << type);
>
> et non pas a la ligne ou tu as splitte ta chaine pour le wrap a 75
> caracteres
>
> je rencontre aussi des soucis lors du make install, ca fait n importe quoi
> dans le rep python g du improviser a la main pour terminer l install.
>
> Il y a clairement de quoi faire avant une release.
> Je prefere le cmake qui passe tout droit :)
>
> Le python setup.py n'est pas a jour et casse lui aussi
>
> Manu
>
> Mathieu Malaterre writes:
>
> > Emmanuel Olart wrote:
> >> Voici l output que je recupere sur RH9 :
> >>
> >>
> >> g++ -DHAVE_CONFIG_H -I. -I. -I../src -I. -I../src
> >> -I/usr/include/python2.2 -I/usr/include/vtk -I/usr/local/include/vtk -g
> >> -O2 -c vtkGdcmReader.cxx -MT vtkGdcmReader.lo -MD -MP -MF
> >> .deps/vtkGdcmReader.TPlo  -fPIC -DPIC -o .libs/vtkGdcmReader.lo
> >> In file included from /usr/include/c++/3.2.2/backward/strstream:51,
> >>                from /usr/local/include/vtk/vtkIOStream.h:31,
> >>                from /usr/local/include/vtk/vtkSystemIncludes.h:49,
> >>                from /usr/local/include/vtk/vtkIndent.h:27,
> >>                from /usr/local/include/vtk/vtkObjectBase.h:46,
> >>                from /usr/local/include/vtk/vtkObject.h:44,
> >>                from /usr/local/include/vtk/vtkObjectFactory.h:46,
> >>                from vtkGdcmReader.cxx:46:
> >> /usr/include/c++/3.2.2/backward/backward_warning.h:32:2: warning:
> >> #warning This file includes at least one deprecated or antiquated
header.
> >> Please consider using one of the 32 headers found in section 17.4.1.2
of
> >> the C++ standard. Examples include substituting the <X> header for the
> >> <X.h> header for C++ includes, or <sstream> instead of the deprecated
> >> header <strstream.h>. To disable this warning use -Wno-deprecated.
> >> vtkGdcmReader.cxx: In member function `int
> >>  vtkGdcmReader::CheckFileCoherence()':
> >> vtkGdcmReader.cxx:242: no match for `vtkOStreamWrapper& <<
std::string&'
> >>  operator
> >
> > Hum...La ligne en question est un string multiligne. Est-ce que tu peux
me
> > renvoyer:
> >
> > $g++ -v
> >
> > J'ai lu quelque part que le support devait effectivement etre supprimé
> > dans les gcc à venir. Est-ce que tu peux confirmer que de faire tout
tenir
> > en une ligne, ca marche:
> >
> > vtkErrorMacro("Removing this file from readed files "  <<
> > FileName->c_str());
> >
> >
> > -ce qui n'est pas le cas dans mon mail à cause du warp à 75 caractères-
> >
> > <snip>
> >
> >> make: *** [all-recursive] Error 1
> >> A noter egalement que dans le Makefile.am du repertoire vtk, les
> >> repertoires d includes et de lib vtk sont mis en dur et non pas
> >> determinés par l'autogen / configure. Je suis donc oblige sur une
config
> >> ou vtk est installe dans /usr/local/ au lieu de /usr de modifier le
> >> Makefile.am a la main avant la compil
> >
> > 1. Je me suis deja exprimé sur le sujet autoconf/autotools.
> > 2. J'ai demandé à LFV d'intégrer vtk.m4 dans le CVS de gdcm
> > 3. On vient de m'apprendre que le support de CMake est refusé pour des
> > prétextes douteux "d'impossibilité d'achat" de bouquin.
> >
> > Je ne voudrais pas me lancer dans un débat stérile, mais j'ai passer pas
> > mal de temps la semaine dernière à mettre à jour les dsp/dsw pour win32.
> > La politique du labo supporte cette architecture mais ne fournis pas les
> > outils pour un support simple -comme cmake-.
> >
> > Bilan on se retrouve avec des scripts m4 -je doute que le labo est *UN*
> > seul bouquin sur le sujet d'ailleurs- et des workspaces win32
> > désynchronisés.
> >
> > my 0.0?
> > /mat
> > Ps: Le bouquin sur CMake je l'ai depuis que je suis allé à Kitware:
> > 24/09/2003 et l'intégration CMake dans Maracas date de bien avant.
> >
> > _______________________________________________
> > Dcmlib mailing list
> > Dcmlib at creatis.insa-lyon.fr
> > http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib




More information about the Dcmlib mailing list