Problems linking DCMTK 3.5.3 with Visual Studio .NET 2003

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
marcus
Posts: 9
Joined: Tue, 2004-11-09, 13:54

Problems linking DCMTK 3.5.3 with Visual Studio .NET 2003

#1 Post by marcus »

Hi,

I have now managed to build DCMTK using Microsoft Visual Studio .NET 2003 and CMake 2.0.5, but I had a problem that stumped me for hours, so I thought I'd share the solution.

My problem was that all of the apps in the dcmpstat directory failed to link, reporting the error:

Code: Select all

LINK : fatal error LNK1181: cannot open input file 'ofstd.lib'
However, all of the DCMTK library files, including ofstd.lib, had been compiled successfully and all of the project settings pointed to the correct library directories.

Initially I thought the problem was with CMake, but eventually I discovered that it is due to a limitation in Visual Studio. The cause of the problem is that the project setting "Configuration Properties->Linker->General->Additional Library Directories" has a limited length!

For all of the projects in the dcmpstat directory there are large numbers of Additional Library Directories. On my system this setting was over 2500 characters long, and Visual Studio couldn't cope. However, some of the DCMTK directories included in this list did not actually exist, and once I had deleted them everything compiled and linked without difficulty.

Would it be possible to modify the CMakeLists.txt files in the DCMTK distribution so that these non-existant directories are removed from the "Additional Library Directories" setting when the build target is Visual Studio .NET 2003?

Also, if anyone has a more recent version of Visual Studio then it would be interesting to know whether Microsoft have removed this limitation. I am using Microsoft Development Environment 2003 Version 7.1.3088

All the best,
Marcus

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

Re: Problems linking DCMTK 3.5.3 with Visual Studio .NET 2003

#2 Post by Jörg Riesmeier »

Strange problem ...
marcus wrote:For all of the projects in the dcmpstat directory there are large numbers of Additional Library Directories. On my system this setting was over 2500 characters long, and Visual Studio couldn't cope. However, some of the DCMTK directories included in this list did not actually exist, and once I had deleted them everything compiled and linked without difficulty.
Could you please tell us which DCMTK directories are listed there that actually do not exist. We are not aware of such problem.

Thanks,
Jörg

marcus
Posts: 9
Joined: Tue, 2004-11-09, 13:54

Re: Problems linking DCMTK 3.5.3 with Visual Studio .NET 2003

#3 Post by marcus »

From the project dcmprscu, for example, all of the following directories are included in the Additional Library Directories setting:

Code: Select all

dcmtk-3.5.3\dcmpstat\$(INTDIR);
dcmtk-3.5.3\dcmpstat\;
dcmtk-3.5.3\ofstd\$(INTDIR);
dcmtk-3.5.3\ofstd\;
dcmtk-3.5.3\dcmdata\$(INTDIR);
dcmtk-3.5.3\dcmdata\;
dcmtk-3.5.3\dcmtls\$(INTDIR);
dcmtk-3.5.3\dcmtls\;
dcmtk-3.5.3\dcmnet\$(INTDIR);
dcmtk-3.5.3\dcmnet\;
dcmtk-3.5.3\imagectn\$(INTDIR);
dcmtk-3.5.3\imagectn\;
dcmtk-3.5.3\dcmimgle\$(INTDIR);
dcmtk-3.5.3\dcmimgle\;
dcmtk-3.5.3\dcmsr\$(INTDIR);
dcmtk-3.5.3\dcmsr\;
dcmtk-3.5.3\dcmsign\$(INTDIR);
dcmtk-3.5.3\dcmsign\;
zlib-1.2.1\lib\$(INTDIR);
zlib-1.2.1\lib\;
libxml2-2.5.7\lib\$(INTDIR);
libxml2-2.5.7\lib\;
openssl-0.9.7d\lib\$(INTDIR);
openssl-0.9.7d\lib\;
dcmtk-3.5.3\ofstd\libsrc\$(INTDIR);
dcmtk-3.5.3\ofstd\libsrc\;
dcmtk-3.5.3\dcmdata\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmdata\libsrc\;
dcmtk-3.5.3\dcmtls\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmtls\libsrc\;
dcmtk-3.5.3\dcmnet\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmnet\libsrc\;
dcmtk-3.5.3\imagectn\libsrc\$(INTDIR);
dcmtk-3.5.3\imagectn\libsrc\;
dcmtk-3.5.3\dcmimgle\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmimgle\libsrc\;
dcmtk-3.5.3\dcmpstat\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmpstat\libsrc\;
dcmtk-3.5.3\dcmsr\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmsr\libsrc\;
dcmtk-3.5.3\dcmsign\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmsign\libsrc\;
But when compiling with Visual Studio most of these directories either do not exist, or do not contain any library files. The only directories that are necessary are:

Code: Select all

dcmtk-3.5.3\ofstd\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmdata\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmtls\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmnet\libsrc\$(INTDIR);
dcmtk-3.5.3\imagectn\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmimgle\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmpstat\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmsr\libsrc\$(INTDIR);
dcmtk-3.5.3\dcmsign\libsrc\$(INTDIR);
zlib-1.2.1\lib\;
libxml2-2.5.7\lib\;
openssl-0.9.7d\lib\;
The project will only compile with Visual Studio .NET 2003 once these unnecessary directories have been removed from the list.


btw- I have used relative directories here to make things more readable, but CMake will actually generate full directory paths. The directory that I have extracted all of the files into is:

C:\Marcus\development\tests\dcmtk\

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

#4 Post by Jörg Riesmeier »

I've forwarded your problem to the colleague who tested DCMTK 3.5.3 with VS .NET 2003. We'll have to wait for his response.

Nevertheless, as far as I can remember he recommended to delete all *.dsp and *.dsw files that are shipped with DCMTK before using CMake to create the *.sln files.

Jörg

anba
DCMTK Tester
Posts: 4
Joined: Wed, 2004-11-10, 19:09

Re: Problems linking DCMTK 3.5.3 with Visual Studio .NET 2003

#5 Post by anba »

I tested the compilation on VS .NET for dcmtk 3.5.3 release candidates and didn't have any problems regarding length of the library path line. But I can confirm that cmake creates a lot of unnecessary library paths as shown in a previous method. With my VS .NET version this does not lead to any problems.

I use a quite old version of VS .NET (without the postfix 2003) which has an older compiler. During my work with other projects I recognized that Microsoft has made big changes in compiler and environment with this version 2003 or later. They are definitely not compatible but I cannot say if they implemented a restriction in the length of library paths. This restriction does not exist in my "old" version.
Andreas Barth

kero
Posts: 1
Joined: Tue, 2004-12-07, 15:57
Location: Ankara - Turkey
Contact:

Additional Library Directories may not be enough...

#6 Post by kero »

Showing the compiler only the paths may not be enough in .net Visual C++, system may also require the exact names of the libraries 2 be used. Try checking the libraries being asked to the Additional Dependencies part in the Linker->Input settings. If the library being asked is not given in there, simply add it and try again. I overcame similar problems a few weeks ago...
goose r we...

youngn
Posts: 8
Joined: Thu, 2005-01-27, 19:33

#7 Post by youngn »

After experiencing the same linking problem in VS2003, I was able to find a somewhat more permanent solution to the problem, so I thought I'd share it. Marcus' original post led me to wonder if there's a way to shorten the "Additional Library Directories" field in a programmatic way without having to actually modify the .vcproj settings manually. Apparently, there are two ways:

1) When running CMakeSetup, check "Show Advanced Values" and turn the "CMAKE_USE_RELATIVE_PATHS" field to ON. This eliminates the long paths incurred by using absolute paths.

2) In the CMakeLists.txt file in each of the "apps" directories, there's a line that looks something like this:

Code: Select all

LINK_DIRECTORIES(${dcmdata_BINARY_DIR} ${ofstd_BINARY_DIR})
The number of unnecessary directories can be reduced somewhat by appending a "libsrc" to each path:

Code: Select all

LINK_DIRECTORIES(${dcmdata_BINARY_DIR}/libsrc ${ofstd_BINARY_DIR}/libsrc)
Do this for each of the CMakeLists.txt files in the various "apps" directories.

I still haven't figured out how to get rid of *all* the unnecessary directories, but this modification along with 1) seems to shorten the "Additional Library Directories" field enough to allow all projects to compile without errors, even when the extra libraries like zlib, png, etc. are all turned on.

Hope that helps.

Thanks to Marcus for pointing out it was a problem with the length of the "Additional Library Directories" field--a key observation without which I'd still be trying to figure out what was wrong! :)

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#8 Post by Thomas Wilkens »

Can you please tell us which version of CMake you are using? When we first added CMake support to DCMTK there was no such field "CMAKE_USE_RELATIVE_PATHS".

I remember writing an email to Kitware, demanding such an option.

youngn
Posts: 8
Joined: Thu, 2005-01-27, 19:33

#9 Post by youngn »

I'm using CMake 2.0 Patch 5.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest