|
»
linking errors
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
linking errors
by Mark Roden
::
Rate this Message:
Hi all,
I'm trying to use the following code, which is more or less entirely copied from page 300 of the 2.4 manual: #include "stdAfx.h" #include "CTSeriesReader.h" #include <string> #include "itkImageFileReader.h" #include "itkGDCMImageIO.h" #include "itkGDCMSeriesFileNames.h" #include "itkImageSeriesReader.h" typedef itk::Image< signed short, 3 > CTImage; typedef itk::Image< signed short, 3 >::Pointer CTPointer; typedef itk::ImageSeriesReader<CTImage> CTReader; CTPointer CTSeriesReader::Produce3DDicomStack(const std::string& inDirectoryName) { CTPointer theReturn = CTImage::New(); //code is borrowed verbatim from ~page 300 of v2.4 of the itk code manual CTReader::Pointer reader = CTReader::New(); typedef itk::GDCMImageIO ImageIOType; ImageIOType::Pointer dicomIO = ImageIOType::New(); reader->SetImageIO(dicomIO); typedef itk::GDCMSeriesFileNames NamesGeneratorType; NamesGeneratorType::Pointer nameGenerator = NamesGeneratorType::New(); nameGenerator->SetUseSeriesDetails(true); nameGenerator->SetDirectory(inDirectoryName); typedef std::vector < std::string > SeriesIdContainer; const SeriesIdContainer& seriesUID = nameGenerator->GetSeriesUIDs(); SeriesIdContainer::const_iterator seriesItr = seriesUID.begin(); SeriesIdContainer::const_iterator seriesEnd = seriesUID.end(); try {//apparently, iterating through the series UIDs can cause crashes, so let's just throw that into a try/catch while(seriesItr!=seriesEnd) { std::cout<<seriesItr->c_str()<<std::endl; seriesItr++; } } catch(itk::ExceptionObject &ex){ std::cout<<ex<<std::endl; return theReturn;//nothing in it yet } std::string seriesIdentifier = seriesUID.begin()->c_str(); typedef std::vector<std::string> FileNamesContainer; FileNamesContainer fileNames = nameGenerator->GetFileNames(seriesIdentifier); reader->SetFileNames(fileNames); try { reader->Update(); } catch(itk::ExceptionObject &ex) { std::cout<<ex<<std::endl; return theReturn; } return reader->GetOutput(); } problem is, I'm getting these linker errors: 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol __imp__UuidCreate@4 referenced in function "private: static bool __cdecl gdcm::Util::GenerateUUID(unsigned char *)" (?GenerateUUID@Util@gdcm@@CA_NPAE@Z) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _gethostbyname@4 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _gethostname@8 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _WSACleanup@0 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _WSAStartup@8 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _SnmpUtilVarBindFree@4 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _SnmpUtilOidNCmp@12 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external symbol _SnmpUtilOidCpy@8 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) 1>C:\Users\Mark\src\ITKTests\ITKTestProject\Debug\ITKTestProject.exe : fatal error LNK1120: 8 unresolved externals This happens on release or debug builds. I'm using itk from the svn trunk with the flat header build. I've included all libraries into the same sln file as this file, and all the itk header files. Everything compiles. I've also tried including the gdcmutil.obj (56k) into the build, but that doesn't work. What can I do to fix this problem? Should I replace the gdcm 2.0 with gdcm 2.1 libraries, or is this a build problem rather than a source problem? Thanks, Mark _____________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by Mark Roden
::
Rate this Message:
Hello again,
I think I solved this problem by using a system-specific build of gdcm rather than the built in libraries. Unfortunately, now the application crashes on ImageIOType::Pointer dicomIO = ImageIOType::New(); Suggesting that the gdcm library must be the one used in itk. Does anyone have any experience with this kind of bug? Thanks, Mark On Tue, Nov 3, 2009 at 11:20 AM, Mark Roden <mmroden@...> wrote: > Hi all, > > I'm trying to use the following code, which is more or less entirely > copied from page 300 of the 2.4 manual: > > > #include "stdAfx.h" > #include "CTSeriesReader.h" > #include <string> > > #include "itkImageFileReader.h" > #include "itkGDCMImageIO.h" > #include "itkGDCMSeriesFileNames.h" > #include "itkImageSeriesReader.h" > > > typedef itk::Image< signed short, 3 > CTImage; > typedef itk::Image< signed short, 3 >::Pointer CTPointer; > typedef itk::ImageSeriesReader<CTImage> CTReader; > > CTPointer CTSeriesReader::Produce3DDicomStack(const std::string& > inDirectoryName) { > > > CTPointer theReturn = CTImage::New(); > > //code is borrowed verbatim from ~page 300 of v2.4 of the itk code manual > CTReader::Pointer reader = CTReader::New(); > > typedef itk::GDCMImageIO ImageIOType; > ImageIOType::Pointer dicomIO = ImageIOType::New(); > reader->SetImageIO(dicomIO); > > typedef itk::GDCMSeriesFileNames NamesGeneratorType; > NamesGeneratorType::Pointer nameGenerator = NamesGeneratorType::New(); > nameGenerator->SetUseSeriesDetails(true); > nameGenerator->SetDirectory(inDirectoryName); > > typedef std::vector < std::string > SeriesIdContainer; > const SeriesIdContainer& seriesUID = nameGenerator->GetSeriesUIDs(); > SeriesIdContainer::const_iterator seriesItr = seriesUID.begin(); > SeriesIdContainer::const_iterator seriesEnd = seriesUID.end(); > try {//apparently, iterating through the series UIDs can cause > crashes, so let's just throw that into a try/catch > while(seriesItr!=seriesEnd) > { > std::cout<<seriesItr->c_str()<<std::endl; > seriesItr++; > } > } > catch(itk::ExceptionObject &ex){ > std::cout<<ex<<std::endl; > return theReturn;//nothing in it yet > } > > std::string seriesIdentifier = seriesUID.begin()->c_str(); > > typedef std::vector<std::string> FileNamesContainer; > FileNamesContainer fileNames = nameGenerator->GetFileNames(seriesIdentifier); > > reader->SetFileNames(fileNames); > try > { > reader->Update(); > } > catch(itk::ExceptionObject &ex) > { > std::cout<<ex<<std::endl; > return theReturn; > } > > return reader->GetOutput(); > } > > problem is, I'm getting these linker errors: > > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol __imp__UuidCreate@4 referenced in function "private: static > bool __cdecl gdcm::Util::GenerateUUID(unsigned char *)" > (?GenerateUUID@Util@gdcm@@CA_NPAE@Z) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _gethostbyname@4 referenced in function "private: static class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" > (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _gethostname@8 referenced in function "private: static class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" > (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _WSACleanup@0 referenced in function "private: static class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" > (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _WSAStartup@8 referenced in function "private: static class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" > (?GetIPAddress@Util@gdcm@@CA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _SnmpUtilVarBindFree@4 referenced in function "int __cdecl > gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _SnmpUtilOidNCmp@12 referenced in function "int __cdecl > gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol _SnmpUtilOidCpy@8 referenced in function "int __cdecl > gdcm::GetMacAddrSys(unsigned char *)" (?GetMacAddrSys@gdcm@@YAHPAE@Z) > 1>C:\Users\Mark\src\ITKTests\ITKTestProject\Debug\ITKTestProject.exe : > fatal error LNK1120: 8 unresolved externals > > This happens on release or debug builds. > > I'm using itk from the svn trunk with the flat header build. I've > included all libraries into the same sln file as this file, and all > the itk header files. Everything compiles. I've also tried including > the gdcmutil.obj (56k) into the build, but that doesn't work. > > What can I do to fix this problem? Should I replace the gdcm 2.0 with > gdcm 2.1 libraries, or is this a build problem rather than a source > problem? > > Thanks, > Mark > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by malat
::
Rate this Message:
On Tue, Nov 3, 2009 at 8:20 PM, Mark Roden <mmroden@...> wrote:
> Hi all, > problem is, I'm getting these linker errors: > > 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external > symbol __imp__UuidCreate@4 referenced in function "private: static You are missing a link to the library: rpcrt4. What I do not understand is that it mention 'itkgdcm' which is the patch gdcm 1.2.x shipped within ITK, but at the same time you mention using GDCM 2.x. Using a combination of the library may work (in theory), but I do not recommend it. Please pick only one GDCM library. HTH -- Mathieu _____________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by Mark Roden
::
Rate this Message:
Hi Mathieu,
I tried using both versions of gdcm. First, I used the version that ships with itk, and got those linker errors. I'll look for that library and linking it in. Second, I tried the advanced itk build option of 'use system gdcm' and used gdcm v 2.0.13 (actually, it was the trunk build, synced yesterday). With that version, everything builds just fine, but then I get a crash when I try to instantiate a gdcmio object. Is there some way to fix this second use, or do I need more linkages to make it work? I thought that gdcm 2.1 would be a better fit for modern dicom images, especially since I'm looking to read in RT images as well, and so need at least the 2.0 versions of the library. Thanks, Mark On Wed, Nov 4, 2009 at 12:31 AM, Mathieu Malaterre <mathieu.malaterre@...> wrote: > On Tue, Nov 3, 2009 at 8:20 PM, Mark Roden <mmroden@...> wrote: >> Hi all, >> problem is, I'm getting these linker errors: >> >> 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external >> symbol __imp__UuidCreate@4 referenced in function "private: static > > You are missing a link to the library: rpcrt4. > > What I do not understand is that it mention 'itkgdcm' which is the > patch gdcm 1.2.x shipped within ITK, but at the same time you mention > using GDCM 2.x. > Using a combination of the library may work (in theory), but I do not > recommend it. > > Please pick only one GDCM library. > > HTH > -- > Mathieu > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by Mark Roden
::
Rate this Message:
Hi Mathieu,
I needed this set of libraries to make it all work: snmpapi.lib rpcrt4.lib wsock32.lib not just rpcrt4.lib. After I included that, running the sample code got me an access violation inside of memcpy when looking for the gdcm dictionary. Turns out, the dictset object is attempting to access a default path, as if I had installed gdcm, rather than using it as a transportable set of libraries that will not require a separate installation. I try to set the string in gdcmconfigure.h for PUB_DICT_PATH to be "..\dicts" rather than a system-specific path, and that does nothing. I'm still getting a memcpy break with the relevant stack trace looking like: msvcp90d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Right="C:/Program Files/ITK/share/gdcm//") Line 927 C++ ITKTestProject.exe!gdcm::DictSet::DictSet() + 0xaa bytes C++ suggesting that there is some hardcoding going on in setting up the dicom dictionaries. Perusing the source code shows that an environment variable is queried before the path in the gdcmconfigure.h file is used; however, no such path variable is set on my system, so the gdcmconfigure.h path should be used instead. It is not being used-- I can tell because I set to a ridiculous value but the string setting in the stack trace is unchanged. I'm rebuilding everything in debug (a process that takes about an hour), so I'll post more once I get a stack trace there. Also, looking at the gdcmcommon.h shows that the signed/unsigned warning is turned off, which maybe should be turned on, especially for those people who are getting bit depth losses when they just read in an image and then write it out again. Thanks, Mark On Wed, Nov 4, 2009 at 6:15 AM, Mark Roden <mmroden@...> wrote: > Hi Mathieu, > > I tried using both versions of gdcm. First, I used the version that > ships with itk, and got those linker errors. I'll look for that > library and linking it in. > > Second, I tried the advanced itk build option of 'use system gdcm' and > used gdcm v 2.0.13 (actually, it was the trunk build, synced > yesterday). With that version, everything builds just fine, but then > I get a crash when I try to instantiate a gdcmio object. Is there > some way to fix this second use, or do I need more linkages to make it > work? I thought that gdcm 2.1 would be a better fit for modern dicom > images, especially since I'm looking to read in RT images as well, and > so need at least the 2.0 versions of the library. > > Thanks, > Mark > > On Wed, Nov 4, 2009 at 12:31 AM, Mathieu Malaterre > <mathieu.malaterre@...> wrote: >> On Tue, Nov 3, 2009 at 8:20 PM, Mark Roden <mmroden@...> wrote: >>> Hi all, >>> problem is, I'm getting these linker errors: >>> >>> 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external >>> symbol __imp__UuidCreate@4 referenced in function "private: static >> >> You are missing a link to the library: rpcrt4. >> >> What I do not understand is that it mention 'itkgdcm' which is the >> patch gdcm 1.2.x shipped within ITK, but at the same time you mention >> using GDCM 2.x. >> Using a combination of the library may work (in theory), but I do not >> recommend it. >> >> Please pick only one GDCM library. >> >> HTH >> -- >> Mathieu >> > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by Mark Roden
::
Rate this Message:
Hi Mathieu,
These problems appear when I use the release build of itk, but not the debug build, so I can't provide any further information. With the debug build, it takes roughly a minute to read a stack of 120 images into a single volume, so I can use it, but I'd rather have the bug fixed. Or, alternatively, a fix to my original code to use gdcm 2.1 instead of the 1.2 that comes with itk. I'm planning on incorporating the rt struct reader code as well, and that's definitely using the later gdcm version. While I could do this all as separate programs, that will make the logic of what I'm trying to do (register images to one another) more complicated than I think it needs to be. Thanks! Mark On Wed, Nov 4, 2009 at 9:37 AM, Mark Roden <mmroden@...> wrote: > Hi Mathieu, > > I needed this set of libraries to make it all work: > > snmpapi.lib > rpcrt4.lib > wsock32.lib > > not just rpcrt4.lib. After I included that, running the sample code > got me an access violation inside of memcpy when looking for the gdcm > dictionary. Turns out, the dictset object is attempting to access a > default path, as if I had installed gdcm, rather than using it as a > transportable set of libraries that will not require a separate > installation. I try to set the string in gdcmconfigure.h for > PUB_DICT_PATH to be "..\dicts" rather than a system-specific path, and > that does nothing. I'm still getting a memcpy break with the relevant > stack trace looking like: > > msvcp90d.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >>::operator=(const > std::basic_string<char,std::char_traits<char>,std::allocator<char> > & > _Right="C:/Program Files/ITK/share/gdcm//") Line 927 C++ > ITKTestProject.exe!gdcm::DictSet::DictSet() + 0xaa bytes C++ > > > suggesting that there is some hardcoding going on in setting up the > dicom dictionaries. Perusing the source code shows that an > environment variable is queried before the path in the gdcmconfigure.h > file is used; however, no such path variable is set on my system, so > the gdcmconfigure.h path should be used instead. It is not being > used-- I can tell because I set to a ridiculous value but the string > setting in the stack trace is unchanged. I'm rebuilding everything in > debug (a process that takes about an hour), so I'll post more once I > get a stack trace there. > > Also, looking at the gdcmcommon.h shows that the signed/unsigned > warning is turned off, which maybe should be turned on, especially for > those people who are getting bit depth losses when they just read in > an image and then write it out again. > > Thanks, > Mark > > > On Wed, Nov 4, 2009 at 6:15 AM, Mark Roden <mmroden@...> wrote: >> Hi Mathieu, >> >> I tried using both versions of gdcm. First, I used the version that >> ships with itk, and got those linker errors. I'll look for that >> library and linking it in. >> >> Second, I tried the advanced itk build option of 'use system gdcm' and >> used gdcm v 2.0.13 (actually, it was the trunk build, synced >> yesterday). With that version, everything builds just fine, but then >> I get a crash when I try to instantiate a gdcmio object. Is there >> some way to fix this second use, or do I need more linkages to make it >> work? I thought that gdcm 2.1 would be a better fit for modern dicom >> images, especially since I'm looking to read in RT images as well, and >> so need at least the 2.0 versions of the library. >> >> Thanks, >> Mark >> >> On Wed, Nov 4, 2009 at 12:31 AM, Mathieu Malaterre >> <mathieu.malaterre@...> wrote: >>> On Tue, Nov 3, 2009 at 8:20 PM, Mark Roden <mmroden@...> wrote: >>>> Hi all, >>>> problem is, I'm getting these linker errors: >>>> >>>> 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external >>>> symbol __imp__UuidCreate@4 referenced in function "private: static >>> >>> You are missing a link to the library: rpcrt4. >>> >>> What I do not understand is that it mention 'itkgdcm' which is the >>> patch gdcm 1.2.x shipped within ITK, but at the same time you mention >>> using GDCM 2.x. >>> Using a combination of the library may work (in theory), but I do not >>> recommend it. >>> >>> Please pick only one GDCM library. >>> >>> HTH >>> -- >>> Mathieu >>> >> > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by malat
::
Rate this Message:
On Wed, Nov 4, 2009 at 7:21 PM, Mark Roden <mmroden@...> wrote:
> Hi Mathieu, > > These problems appear when I use the release build of itk, but not the > debug build, so I can't provide any further information. You cannot mix release and debug builds, this has never work and will never work on any Win32+M$ compiler. I even thought cmake 2.6 was very picky about that, and would not let you shoot yourslef in the foot... > With the debug build, it takes roughly a minute to read a stack of 120 > images into a single volume, so I can use it, but I'd rather have the > bug fixed. Or, alternatively, a fix to my original code to use gdcm > 2.1 instead of the 1.2 that comes with itk. I'm planning on > incorporating the rt struct reader code as well, and that's definitely > using the later gdcm version. While I could do this all as separate > programs, that will make the logic of what I'm trying to do (register > images to one another) more complicated than I think it needs to be. You may want to create a fake cmakelists.txt, eg: $ cat CMakeLists.txt add_subdirectory(GDCM) # setup ITK_USE_SYSTEM_GDCM add_subdirectory(ITK) To make sure you are building GDCM + ITK using the exact same compiler flags. Good luck ! -- Mathieu _____________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
|
|
|
Re: linking errors
by Mark Roden
::
Rate this Message:
OK, got the release/debug thing to work, at least for now. It's still
the gdcm version that comes with itk, not the newest hotness. Just required quite a bit of sln modifications, where both the debug and the release builds need to point to their own particular versions of the itk libraries, headers, and binaries. I'm still confused about the environment variable, because I still can't find it. Thanks for that, Mark On Wed, Nov 4, 2009 at 12:07 PM, Mark Roden <mmroden@...> wrote: > Hi Mathieu, > > > > On Wed, Nov 4, 2009 at 11:50 AM, Mathieu Malaterre > <mathieu.malaterre@...> wrote: >> Mark, >> >> On Wed, Nov 4, 2009 at 6:37 PM, Mark Roden <mmroden@...> wrote: >>> Hi Mathieu, >>> >>> I needed this set of libraries to make it all work: >>> >>> snmpapi.lib >>> rpcrt4.lib >>> wsock32.lib >> >> I do not understand why this is failing for you. Do you have a >> particular setup ? What is your OS, compiler ? > > Windows 7, vs2008. rpcrt4.lib alone did not solve the linker errors, > the other two libraries were necessary to fix it. I'm just letting > you know for the future. > >> >>> not just rpcrt4.lib. After I included that, running the sample code >>> got me an access violation inside of memcpy when looking for the gdcm >>> dictionary. Turns out, the dictset object is attempting to access a >>> default path, as if I had installed gdcm, rather than using it as a >>> transportable set of libraries that will not require a separate >>> installation. I try to set the string in gdcmconfigure.h for >>> PUB_DICT_PATH to be "..\dicts" rather than a system-specific path, and >>> that does nothing. I'm still getting a memcpy break with the relevant >>> stack trace looking like: >> >> GDCM expect things in particular layout (typically what make install, >> or what cpack is doing). If you do not like this layout, you have to >> setup an env var saying where are the Part3.xml files (this is not >> required at any point by ITK stuff). >> See GDCM_RESOURCES_PATH en var. > > I have no such environmental variable set, and I've run both gdcm and > itk INSTALL from cmake. Even so, if it's from an environment > variable, why would it work in debug and not release? > >> >>> >>> suggesting that there is some hardcoding going on in setting up the >> >> sed s/hardcoding/{default handling, user control using env var}/g > > right. Except that I have no such environment variable set, according > to my system settings. > >> >>> dicom dictionaries. Perusing the source code shows that an >>> environment variable is queried before the path in the gdcmconfigure.h >>> file is used; however, no such path variable is set on my system, so >>> the gdcmconfigure.h path should be used instead. It is not being >>> used-- I can tell because I set to a ridiculous value but the string >>> setting in the stack trace is unchanged. I'm rebuilding everything in >>> debug (a process that takes about an hour), so I'll post more once I >>> get a stack trace there. >>> >>> Also, looking at the gdcmcommon.h shows that the signed/unsigned >>> warning is turned off, which maybe should be turned on, especially for >> >> I have never heard of "signed/unsigned warning is turned off" before. >> What are you talking about ? > > These warnings are turned off in gdcmcommon.h that is created by itk/install: > > // 'identifier' : class 'type' needs to have dll-interface to be used by > // clients of class 'type2' > #pragma warning ( disable : 4251 ) > // non dll-interface class 'type' used as base for dll-interface class 'type2' > #pragma warning ( disable : 4275 ) > // 'identifier' : identifier was truncated to 'number' characters in the > // debug information > #pragma warning ( disable : 4786 ) > //'identifier' : decorated name length exceeded, name was truncated > #pragma warning ( disable : 4503 ) > // C++ exception specification ignored except to indicate a > // function is not __declspec(nothrow) > #pragma warning ( disable : 4290 ) > // signed/unsigned mismatch > #pragma warning ( disable : 4018 ) > // return type for 'identifier' is '' (ie; not a UDT or reference to UDT. Will > // produce errors if applied using infix notation > #pragma warning ( disable : 4284 ) > // 'type' : forcing value to bool 'true' or 'false' (performance warning) > // //#pragma warning ( disable : 4800 ) > >> >>> those people who are getting bit depth losses when they just read in >>> an image and then write it out again. >> >> There are two mechanism involve here: ITK and GDCM. GDCM has a nightly >> regression system and we (ie. ctest+cdash) checks that image is >> identical at *bit level*. >> My guess is that you are not using the proper Pixel Type in ITK, which >> is a current -recurring- issue on this mailing list. Please search the >> archives. > > I'm using signed short. > > The nightly builds are ver 2.1, yet the itk is 1.2.4, right? Is there > a way to use 2.1 with itk? > > Now, the next email: >>> These problems appear when I use the release build of itk, but not the >>> debug build, so I can't provide any further information. >> >> You cannot mix release and debug builds, this has never work and will >> never work on any Win32+M$ compiler. I even thought cmake 2.6 was very >> picky about that, and would not let you shoot yourslef in the foot... > > I'm rebuilding entirely from scratch for both. Or are you suggesting > I shouldn't use release libs with a debug program? I'd agree with > this approach, which is why I wanted to build all of itk in dlls > instead of libs, but I'm told that's just not the way it's done. I've > successfully used release dlls with debug programs previously, but not > statically linked libs. > > >> >>> With the debug build, it takes roughly a minute to read a stack of 120 >>> images into a single volume, so I can use it, but I'd rather have the >>> bug fixed. Or, alternatively, a fix to my original code to use gdcm >>> 2.1 instead of the 1.2 that comes with itk. I'm planning on >>> incorporating the rt struct reader code as well, and that's definitely >>> using the later gdcm version. While I could do this all as separate >>> programs, that will make the logic of what I'm trying to do (register >>> images to one another) more complicated than I think it needs to be. >> >> You may want to create a fake cmakelists.txt, eg: >> >> $ cat CMakeLists.txt >> add_subdirectory(GDCM) >> # setup ITK_USE_SYSTEM_GDCM >> add_subdirectory(ITK) > > I'm not using CMake, I'm using the evil corporate overlord Micro$oft > development tools. > >> >> To make sure you are building GDCM + ITK using the exact same compiler flags. > > I'm now just using the gdcm that's part of itk. Unless you're telling > me that your exact example code will work with 2.1, then I'll go > through and do a complete rebuild all the way through to test, but it > didn't work before. > > Thanks, > Mark > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
|
|
Re: linking errors
by Luis Ibanez
::
Rate this Message:
Hi Mark,
As Mathieu pointed out, you should NOT mix code that was build for Debug, with code that was build for Release. In Windows, You must have a consistent build process: where ALL your code is build for Debug or ALL your code is build for Release. The Linker will warn you when you are mixing compilation modes, and if you have been using the /FORCE flag in the Visual Studio IDE, you are just asking for trouble. :-) Are you using CMake to configure your application ? Most of these issues are taken care of by CMake... You shouldn't have to deal with them. Luis ---------------------------------------------------------------------- On Wed, Nov 4, 2009 at 4:44 PM, Mark Roden <mmroden@...> wrote: > OK, got the release/debug thing to work, at least for now. It's still > the gdcm version that comes with itk, not the newest hotness. Just > required quite a bit of sln modifications, where both the debug and > the release builds need to point to their own particular versions of > the itk libraries, headers, and binaries. I'm still confused about > the environment variable, because I still can't find it. > > Thanks for that, > Mark > Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://www.kitware.com/products/protraining.html Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-users |
| Free embeddable forum powered by Nabble | Forum Help |
