[Insight-users] linking errors

[Mark Roden]

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 at gmail.com> 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 at gmail.com> wrote:
>> On Tue, Nov 3, 2009 at 8:20 PM, Mark Roden <mmroden at gmail.com> wrote:
>>> Hi all,
>>> problem is, I'm getting these linker errors:
>>>
>>> 1>itkgdcm.lib(gdcmUtil.obj) : error LNK2019: unresolved external
>>> symbol __imp__UuidCreate at 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
>>
>