another compiling error

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
Hanu
Posts: 2
Joined: Wed, 2006-04-19, 15:45

another compiling error

#1 Post by Hanu »

Hi, all!

I try to change the old dcmtk 3.5.0 to the present 3.5.4.

The programmer who startet my project is not available anymore, so I stand on my own. In the project there are 4 dcmtk librarys included (dcmdata, dcmimage, dcmimgle, ofstd)
The old version was running perfect, but now I got problems with compiling the interface files.

I got 76 errors like these:
"dcmtk354\ofstd\include\dcmtk\ofstd\ofstring.h(817) : error C2872: 'ostream' : Mehrdeutiges Symbol"

Could anybody give me an idea?

Thx, Hanu

But anyway, the reason why I did this was, I got DICOMs from a TOSHIBA CT from Switzerland, which hab a strange Format and could also not be shown by different dicom viewers.
For example, instead of window and center which produces normally values like 1500\3500, whith these dicoms I got values like 2500\2500\3600. The method di->getDepth() gave 16 bits instead of 12. What kind of data did I get?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1459
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by Marco Eichelberg »

This problem is documented in the INSTALL file in DCMTK:
4. Visual C++ contains two different implementations of iostreams which should never be mixed within one application because this may cause application errors that are hard to find. The old, now deprecated implementation uses the traditional cfront header files <iostream.h> etc. The new implementation uses <iostream> etc. as defined in ANSI/ISO ++. DCMTK can be configured to use either of the two interfaces. This behaviour can be changed in "config/include/dcmtk/config/cfwin32.h" where the symbol USE_STD_CXX_INCLUDES is declared.

NOTE: Previous releases of DCMTK (3.5.1 and older) used the old interface when compiled with Visual C++ 6.0. When updating software that uses DCMTK as a library, make sure that the use of the iostream library is consistent throughout the complete application!
You application probably uses both <iostream.h> and <iostream> or <ostream.h> and <ostream> which causes this error message because with newer MSVC editions one header file will put ostream into namespace std and the other header will put it into global namespace.

Hanu
Posts: 2
Joined: Wed, 2006-04-19, 15:45

Great...

#3 Post by Hanu »

...thanks, that helped a lot!

Reckless of the danger to make a fool of myself, I got a kind of the following linker errors:


ibcimtd.lib(_ios.obj) : error LNK2005: "public: virtual __thiscall ios::~ios(void)" (??1ios@@UAE@XZ) bereits in msvcirtd.lib(MSVCIRTD.dll) definiert
libcimtd.lib(mtlock.obj) : error LNK2005: __mtlock bereits in msvcirtd.lib(MSVCIRTD.dll) definiert
libcimtd.lib(mtlock.obj) : error LNK2005: __mtunlock bereits in msvcirtd.lib(MSVCIRTD.dll) definiert
libcimtd.lib(ostream.obj) : error LNK2005: "public: class ostream & __thiscall ostream::operator<<(char const *)" (??6ostream@@QAEAAV0@PBD@Z) bereits in msvcirtd.lib(MSVCIRTD.dll) definiert
libcimtd.lib(ostream.obj) : error LNK2005: "public: class ostream & __thiscall ostream::flush(void)" (?flush@ostream@@QAEAAV1@XZ) bereits in msvcirtd.lib(MSVCIRTD.dll) definiert
LIBCMTD.lib(dosmap.obj) : error LNK2005: __errno bereits in msvcrtd.lib(MSVCRTD.dll) definiert


What does ist mean? It looks a bit similar to the iostream problems.

I'm not so trained with programming and writing in english, particularly stuff like libarys causes me great stomach pains. So thanks for any concern to that,

Hanu

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1459
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#4 Post by Marco Eichelberg »

See FAQ #26.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 0 guests