[Insight-developers] shared_libraries forced to OFF on win32 + MSVC ??

Alexandre GOUAILLARD agouaillard at gmail.com
Wed May 11 08:48:12 EDT 2011


Great.

That answers my question: I was indeed missing something.

I will work on the other solution then.

BTW, did anybody investigate shared vnl?

alex.


On Wed, May 11, 2011 at 7:48 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Alex,
>
> Here are the comments of a commit I made in March:
>
> commit 2fc4688c8475fa9cbc69d51f70c57fbd43e87c08
> Author: Bill Lorensen <bill.lorensen at gmail.com>
> Date:   Sat Mar 19 12:22:02 2011 -0400
>
>     ENH: Shared libraries for ITK Modular
>
>     ITK can only support one shared library. Prior to this change:
>     http://review.source.kitware.com/#change,419
>     there was only one shared library ITKCommon in ITK on windows. Because
>     of vnl limitations, we can only safely have one shared lib.
>
>     Quoting Bill Hoffman:
>     "Without figuring out how to make vnl shared, I don't think that we
>     can safely have more than one dll in ITK. Dll's are an all or nothing
>     type of thing. I think I remember why this was done in the first
>     place. The main driving force for the original ITKCommon being shared
>     was so that plugins could be done for VolView. With all static ITK,
>     the trouble was that each plugin got its own copy of the modified time
>     class static from ITKObject. This of course totally broke the
>     pipeline. So, I think that we should have one ITK dll as we did in
>     the past, and it should be the one that contains the static for
>     modified time. That way plugin type applications can still be created
>     against ITK. I will also investigate making vnl shared, but that
>     maybe too hard..."
>
>
> On Wed, May 11, 2011 at 5:34 AM, Alexandre GOUAILLARD
> <agouaillard at gmail.com> wrote:
>>
>> dear all,
>>
>> we were investigating today some linking errors on GDCM, just to
>> realize it seems that BUILD_SHARED_LIBS is forced to OFF on win32 +
>> MSVC, even if you choose to set it to on with ccmake, and if the
>> CMakeCaches shows it as ON.
>> in CMake/ITKPlatformSpecificChecks.cmake
>> line 52
>> """
>> if(WIN32)
>>   if(CMAKE_COMPILER_IS_GNUCXX)
>>  ...
>>   else(CMAKE_COMPILER_IS_GNUCXX)
>>  ...
>>   set(BUILD_SHARED_LIBS OFF)   <<===== HERE
>>  endif(CMAKE_COMPILER_IS_GNUCXX)
>> endif(WIN32)
>> """
>>
>> Now, is there any reason for that? There is an ITK_BUILD_SHARED_LIBS
>> symbol that is getting defined, but a lot of the modules and
>> especially the submodules still use the main cmake's BUILD_SHARED_LIBS
>> symbol.
>>
>> The bad news is that of course, setting things right and turning share
>> libs on makes the build explode (353 errors and counting). There will
>> be a lot of EXPORT and dependency checking to be done. But that s
>> another story.
>>
>> Are we missing anything?
>>
>> alex, drew and XR
>> _______________________________________________
>> 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://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-developers
>
>


More information about the Insight-developers mailing list