[Insight-users] linking errors

[Mark Roden]

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 at gmail.com> 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 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
>>>
>>
>