[Insight-users] Compile problems - Red Hat Enterprise WS-3;
cmake 2.0.2 ; ITK from CVS ; DICOM parser subdirectory
Atwood, Robert C
r.atwood at imperial.ac.uk
Mon Jul 5 08:37:41 EDT 2004
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeOutput.log.gz
Type: application/x-gzip
Size: 2242 bytes
Desc: CMakeOutput.log.gz
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040705/f3a275b5/CMakeOutput.log-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeError.log.gz
Type: application/x-gzip
Size: 2857 bytes
Desc: CMakeError.log.gz
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040705/f3a275b5/CMakeError.log-0001.bin
More information about the Insight-users
mailing list