[Insight-users] Compile problems - Red Hat Enterprise WS-3; c make 2.0.2 ; ITK from CVS ; DICOM parser subdirectory

Miller, James V (Research) millerjv at crd.ge.com
Tue Jul 6 09:42:23 EDT 2004


Robert, 

Can you try compiling this program using your version of g++?

#include <list>
int main(int, char*[])
{ 
  std::list<int>();
  return 0;
}

This is the exact code from TestForSTDNamespace.cxx. I want to see if
your compiler can build this without throwing CMake into the mix.

Jim



-----Original Message-----
From: Atwood, Robert C [mailto:r.atwood at imperial.ac.uk]
Sent: Monday, July 05, 2004 8:38 AM
To: Miller, James V (Research)
Cc: Insight-users (E-mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


Jim: 

To clarify, it was not installing cmake that was the problem, it was
that cmake did not appear to honour the alternate prefix for installing
the compiled ITK, in the case where:
 I had updated ITK from CVS, 
 I trying to rebuild the latest version in the same build tree (to use
that feature of Make which automates rebuilding only those objects for
which the sources are changed) and, 
 I wished to use my own installation prefix to separate the(possibly
unstable)  installation from the previous one.

Therefore I tried updating to a newer CMAKE (1.8 -> 2.0.2). Due to the
order in which I tried the possible resolutions, I could not yet verify
if this is a problem with CMAKE 2.0.2. Originally I did not encounter
the &string problem, presumably due to the objects in the DICOM-parser
subdirectory not requiring rebuilding according to Make, however I
encoutered the prefix problem. Then I tried a clean build tree, and
encountered the &string problem. Then I tried the updated CMAKE, fresh
CVS checkout, and empty build tree; as I realized that I had updated the
Redhat installation since last time I built the ITK and figured that may
be causing the problems. This seems the most likely , but which feature
of the new Redhat is doing it, I cannot figure out so far.


I installed CMAKE from binary. 

I guess CMAKE_ROOT  is 
/usr/local/share/CMake
 according to the contents of CMakeCache.txt:

#grep CMAKE_ROOT *
CMakeCache.txt:CMAKE_ROOT:INTERNAL=/usr/local/share/CMake
UseITK.cmake:
INCLUDE(${CMAKE_ROOT}/Modules/CMakeImportBuildSettings.cmake

Yes, the file exists in that location:

[root at xe01 Modules]# pwd
/usr/local/share/CMake/Modules

[root at xe01 Modules]# ls -1 TestForSTD*
TestForSTDNamespace.cmake
TestForSTDNamespace.cxx

The contents of the file:

#
# check if the compiler supports std:: on stl classes
#
# CMAKE_NO_STD_NAMESPACE - defined accoreding to the results
#
IF("CMAKE_STD_NAMESPACE" MATCHES "^CMAKE_STD_NAMESPACE$")
  MESSAGE(STATUS "Check for STD namespace")
  TRY_COMPILE(CMAKE_STD_NAMESPACE  ${CMAKE_BINARY_DIR}
    ${CMAKE_ROOT}/Modules/TestForSTDNamespace.cxx
    OUTPUT_VARIABLE OUTPUT)
  IF (CMAKE_STD_NAMESPACE)
    MESSAGE(STATUS "Check for STD namespace - found")
    SET (CMAKE_NO_STD_NAMESPACE 0 CACHE INTERNAL
         "Does the compiler support std::.")
    FILE(APPEND ${CMAKE_BINARY_DIR}/CMakeOutput.log
      "Determining if the CXX compiler has std namespace passed with "
      "the following output:\n${OUTPUT}\n\n")
  ELSE (CMAKE_STD_NAMESPACE)
    MESSAGE(STATUS "Check for STD namespace - not found")
    SET (CMAKE_NO_STD_NAMESPACE 1 CACHE INTERNAL
       "Does the compiler support std::.")
    FILE(APPEND ${CMAKE_BINARY_DIR}/CMakeError.log
      "Determining if the CXX compiler has std namespace failed with "
      "the following output:\n${OUTPUT}\n\n")
  ENDIF (CMAKE_STD_NAMESPACE)
ENDIF("CMAKE_STD_NAMESPACE" MATCHES "^CMAKE_STD_NAMESPACE$")

This  allows me to locate the relevent section in CMakeError.log:

Determining if the CXX compiler has std namespace failed with the
following output:
Building object file TestForSTDNamespace.o...
c++ -o TestForSTDNamespace.o              -c
/usr/local/share/CMake/Modules/TestForSTDNamespace.cxx
Building executable
/sources/local/ITK_build/CMakeTmp/cmTryCompileExec...
c++               -fPIC  TestForSTDNamespace.o    -o
/sources/local/ITK_build/CMakeTmp/cmTryCompileExec -rdynamic
TestForSTDNamespace.o(.gnu.linkonce.t._ZNSt14__simple_allocISt10_List_no
deIiESt24__default_alloc_templateILb1ELi0EEE8allocateEj+0x27): In
function `std::__simple_alloc<std::_List_node<int>,
std::__default_alloc_template<(bool)1, (int)0> >::allocate(unsigned)':
: undefined reference to `std::__default_alloc_template<(bool)1,
(int)0>::allocate(unsigned)'
TestForSTDNamespace.o(.gnu.linkonce.t._ZNSt14__simple_allocISt10_List_no
deIiESt24__default_alloc_templateILb1ELi0EEE10deallocateEPS1_j+0x23): In
function `std::__simple_alloc<std::_List_node<int>,
std::__default_alloc_template<(bool)1, (int)0>
>::deallocate(std::_List_node<int>*, unsigned)':
: undefined reference to `std::__default_alloc_template<(bool)1,
(int)0>::deallocate(void*, unsigned)'
TestForSTDNamespace.o(.eh_frame+0x12): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
gmake: *** [/sources/local/ITK_build/CMakeTmp/cmTryCompileExec] Error 1

Hope it helps.
Robert






-----Original Message-----
From: Miller, James V (Research) [mailto:millerjv at crd.ge.com] 
Sent: 02 July 2004 18:21
To: Atwood, Robert C
Cc: Insight-users (E-mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


This is a bit strange.  The DICOM_NO_STD_NAMESPACE should have been
commented out for the compiler you are using.  This flag is set by
CMake.  From the Insight/Utilities/DICOMParser/CMakeLists.txt file

INCLUDE(${CMAKE_ROOT}/Modules/TestForSTDNamespace.cmake)
SET(DICOM_NO_STD_NAMESPACE ${CMAKE_NO_STD_NAMESPACE})

So, CMake should be testing whether the compiler has an std:: namespace 
or not.  One of your messages indicated that you were having problems 
installing CMake.  Does the TestForSTDNamespace.cmake module exist in 

${CMAKE_ROOT}/Modules/TestForSTDNamespace.cmake

Jim

-----Original Message-----
From: Atwood, Robert C [mailto:r.atwood at imperial.ac.uk]
Sent: Friday, July 02, 2004 12:17 PM
To: Miller, James V (Research)
Cc: Insight-users (E-mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


Jim: 

Yes, here is the information (plus the command I used to echo it)

I can see that this differes from the same file on another system where
I have previously compiled the ITK (a while ago) ,ie. the
DICOM_NO_STD_NAMESPACE is not defined in the other system, it is
commented out. 


Thanks


Robert



sh-2.05b# cat DICOMCMakeConfig.h

#ifndef __DICOMCMakeConfig_h_
#define __DICOMCMakeConfig_h_

/* #undef DICOM_DLL */
/* #undef DICOM_STATIC */
#define DICOM_ANSI_STDLIB
#define DICOM_NO_STD_NAMESPACE

#define DICOMPARSER_NAMESPACE itkdicomparser
#endif

sh-2.05b#



-----Original Message-----
From: Miller, James V (Research) [mailto:millerjv at crd.ge.com] 
Sent: 02 July 2004 16:39
To: Atwood, Robert C; Insight-users (E-mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


Robert,

In your build tree, is there a file under Utilities/DICOMParser called
DICOMCMakeConfig.h?

Can you send us the contents of that file?

Jim	

-----Original Message-----
From: Atwood, Robert C [mailto:r.atwood at imperial.ac.uk]
Sent: Friday, July 02, 2004 10:57 AM
To: ITK Users (E-Mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


Original message attatchemnts were too big for the list, here are just
the initial make output and only the cvs tags for the entries related to
DICOM 



-----Original Message-----
From: Atwood, Robert C 
Sent: 02 July 2004 14:48
To: 'Luis Ibanez'
Cc: ITK Users (E-Mail)
Subject: RE: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory


Example error message: 

Building object file DICOMFile.o...
In file included from
/sources/local/ITK_cvs/Utilities/DICOMParser/DICOMFile.cxx:29:
/sources/local/ITK_cvs/Utilities/DICOMParser/DICOMFile.h:51: error:
parse error
   before `&' token

(several more like this)



OKAY! OKAY! I am beginning to hate C++ already. Give me plain C! 

>You should *NEVER* use "using namespace std;"
I said it 'might' be solved this way... not that it 'should' be solved
this way :-). 

sh-2.05b# grep -r 'using namespace std' *
Code/Algorithms/itkGradientDifferenceImageToImageMetric.txx:using
namespace std;
Code/Common/itkWindowedSincInterpolateImageFunction.txx:using namespace
std; ... Someone uses this method...



The version of ITK, as I mentioned in the subject, was checked out via
anonymous CVS. This was originally done yesterday (July 1 2004) CVS
status results attatched for more detail. This was created with

cvs upd -C 
cvs status > itk_version.txt 

(so the examples are with TODAY's cvs July 2 2004 but there is no change
in the results)

I had some other problems to do with updating the previous checkout and
recompiling, I am not yet sure if it is a cmake issue or just me doing
something incorrect. However, ignoring this, I just checked out a whole
fresh tree which I called ITK_cvs, and created a fresh new build
directory which I called ITK_build

I used:

 
cd ITK_build
ccmake ../ITK_cvs

 BUILD_EXAMPLES                   ON
 BUILD_SHARED_LIBS                ON
 BUILD_TESTING                    ON
 CMAKE_BACKWARDS_COMPATIBILITY    2.0
 CMAKE_BUILD_TYPE                 Release
 CMAKE_INSTALL_PREFIX             /usr/local/encap/ITK-1.8.0.4

[c]
[g]
make >& make_output.txt
make clean
make -k >make_k_output.txt

(-k to 'keep going' after the error, to find more errors


These files, itk_version.txt, make_output.txt, and make_k_output.txt are
attatched and contain all the error messages Here is the first one,
there are many more.



Building object file DICOMFile.o...
In file included from
/sources/local/ITK_cvs/Utilities/DICOMParser/DICOMFile.cxx:29:
/sources/local/ITK_cvs/Utilities/DICOMParser/DICOMFile.h:51: error:
parse error
   before `&' token


The ccmake problem is that the process did not seem to honour a new
CMAKE_INSTALL_PREFIX set via ccmake, for an updated version; ie

ccmake 
...
CMAKE_INSTALL_PREFIX             /usr/local/encap/ITK-1.8.0.4
...
[c]
[g]
make 
make install

just installed into the last prefix I had set a while ago
(/usr/local/encap/ITK-1.8.0.2) Fortunately I still have the base
ITK-1.8.0  (I use 1.8 for cvs checkouts of the head revision that are
later than the 1.6, and .0.n for each time I check out from CVS and
recompile and install but this may not be consistent with your usage,
please see the itk_version.txt file for the cvs revision numbers of
specific files)   

Now I cannot tell if ccmake 2.0.2 does this or not because I have not
managed a successful build of ITK after upgrading the ccmake
 

Robert



-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
Sent: 01 July 2004 21:25
To: Atwood, Robert C
Cc: ITK Users (E-Mail)
Subject: Re: [Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory




Hi Robert,

Please *NEVER* open namespaces !

That defeats the purpose of using namespaces.

You should *NEVER* use

         "using namespace std;"

or

         "using namespace itk;"


Please post the errors messages that you are getting.

If the compiler is complainng about "string", the real
solution is to specify its namespace like

                   std::string


instead of opening the namespace and exposing all the
symbols

In what version of ITK are you encountering this problem ?


Please let us know.


    Thanks


      Luis



-----------------------
Atwood, Robert C wrote:

> Dear ITK folks
> 
> I get several messages due to the compiler not recognizing the
> 'string' macro/datatype/whatever it is; this might be solved by 
> putting
> 
> using namespace std;
> 
> into the top of several files in the Utilities/DICOMParser .
> 
> 
> Here are some details (I tried  using ccmake 1.8 first, then upgraded
> to see if that was the problem)
> 
> sh-2.05b# ccmake --version
> ccmake version 2.0.2
> 
> sh-2.05b# rpm -q glibc
> glibc-2.3.2-95.20
> 
> sh-2.05b# rpm -q gcc
> gcc-3.2.3-24
> 
> 
> I seem to recall having this problem before, but I cannot remember if
> it was with this (ITK) or some other software package..I think it also

> has something to do with the level of gcc or glibc ?
> 
> Robert
> 
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 




More information about the Insight-users mailing list