[Insight-users] linking errors

[Mark Roden]

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 at gmail.com> wrote:
> Hi Mathieu,
>
>
>
> On Wed, Nov 4, 2009 at 11:50 AM, Mathieu Malaterre
> <mathieu.malaterre at gmail.com> wrote:
>> Mark,
>>
>> On Wed, Nov 4, 2009 at 6:37 PM, 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
>>
>> 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
>