Hi,
you are right, there shouldn't be a difference in compiling Poco during the
superbuild and using Poco later in MITK. In our next bugsquashing session on
Wednesday I'll have a look at this and determine if it's best to set
_WIN32_WINNT during the superbuild which affects all third party libraries or
to set _WIN32_WINNT only for Poco as additional argument in
CMakeExternals/Poco.cmake if the first case fails. Another solution might be to
set POCO_NO_UNWINDOWS at this place instead.
We let you know as soon as we fixed this issue and how we fixed it.
Thanks for the findings! :-)
Best,
Stefan
http://msdn.microsoft.com/en-US/library/6sehtctf.aspx
Von: Rachit Jain [mailto:[email protected]]
Gesendet: Donnerstag, 10. Oktober 2013 16:44
An: Pierre-Yves Menguy; Kislinskiy, Stefan
Cc: [email protected]
Betreff: Re: [mitk-users] Migration from MITK version 2013.06.0 to MITK version
2013.09.0
Hi Stefan, Pierre-Yves
Thanks for suggestions.
My finding is that in CMakeLists.txt of MITK at LN: 326, we have a section:
if(MITK_USE_SUPERBUILD)
include("${CMAKE_CURRENT_SOURCE_DIR}/SuperBuild.cmake")
return()
endif()
So if somebody is using superbuild (like me), -D_WIN32_WINNT=0x0501 will not be
set. As this setting is there at LN: 464
if(WIN32)
set(MITK_CXX_FLAGS "${MITK_CXX_FLAGS} -D_WIN32_WINNT=0x0501
-DPOCO_NO_UNWINDOWS -DWIN32_LEAN_AND_MEAN")
set(MITK_CXX_FLAGS "${MITK_CXX_FLAGS} /wd4231") # warning C4231: nonstandard
extension used : 'extern' before template explicit instantiation
endif()
So I am wondering why not to have this before LN:326 where we check for
superbuild. Is it intentional, please share your knowledge on this.
In general, I have solved my problem by adding /D_WIN32_WINNT=0x0501 (with
other CXX flags) in CMake GUI of MITK. Then built MITK and did the same
/D_WIN32_WINNT=0x0501 with my application and built and it worked fine.
I would request you put some light on why not to place the if(WIN32) before
superbuild check in MITK CMakeLists.txt itself, because then we need not to add
any other #define to includes windows.h.
Thanks and Regards
Rachit Jain
On Thu, Oct 10, 2013 at 2:29 PM, Pierre-Yves Menguy
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I was trying to realize a small proof-of-concept at the attention of a
colleague, when I encountered the same bug of UnWindows.h as you. I found
differents posts stating about "POCO_NO_UNWINDOWS" in CMake, but to no
difference.
The only work-around I found at the moment is to include <Windows.h> to prevent
ITK to set his own default value (itkThreadSupport.h)
Use this code snippet :
#if _WIN32
#include <Windows.h>
#endif
It fixed the problem for me. As Stefan stated, you may have a correct line to
insert this.
Regards,
Pierre-Yves Menguy
On 10 October 2013 10:29, Rachit Jain
<[email protected]<mailto:[email protected]>> wrote:
Hi All
Came to know about new MITK version 2013.09.0, so was curious to try and use it.
My application (C++ using VS2010, QT 4.8.4 on windows 7 64 bit) was using MITK
2013.06.0 and while moving to version 2013.09.0, I got some minor issues that I
fixed, so sharing with all of you so that everybody can take benefit out of it:
1. The path of CppMicroServices is changed from
Core/Code/CppMicroServices/include to Core/CppMicroServices/include
2. Because of new QWT version 6.1.0, classes like QwtIntervalData,
QwtDoubleRect do not exist anymore. So refactoring is required. This link might
be helpful: http://www.qtcentre.org/archive/index.php/t-49691.html
3. Header files have been changed from mitkModuleRegistry.h to
usModuleRegistry.h. Similarly Module and ModuleRegistry classes are not in mitk
namespace anymore, they are in US_NAMESPACE namespace.
There is one issue which I am not able to fix yet, i.e. related to UnWindows.h,
I see a section that says:
#if defined(_WIN32_WINNT) && (_WIN32_WINNT < 0x0501)
#error Unsupported Windows version.
#elif !defined(_WIN32_WINNT)
// define minimum supported
#define _WIN32_WINNT 0x0501
#endif
When I am building my application, it gives me a compilation error saying
"Unsupported Windows version". I commented the #error, just for testing
purpose, then my application compiles but fails to run. I searched in Cmake
settings of MITK, but could not find anything specific related to this.
Please share if you have encountered the same issue or know how to fix it.
Thanks and Regards
Rachit Jain
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
