Hi,
I did read the article. The point is that I am trying to port a number of
very large projects to CMake that have been always build without code
instrumentation, which I am convinced is the best and optimal way of doing it.
But in this case the code instrumentation is not practical for a number of
reasons. What I have done works except for this little detail I mentioned in
the mail.
Thanks anyway.
Pere
On Dec 21, 2010, at 4:21 PM, Michael Jackson wrote:
> You will want to read this article:
>
> http://www.cmake.org/Wiki/BuildingWinDLL
> ___________________________________________________________
> Mike Jackson www.bluequartz.net
> Principal Software Engineer [email protected]
> BlueQuartz Software Dayton, Ohio
>
> On Dec 21, 2010, at 10:13 AM, Pere Mato Vila wrote:
>
>> Dear all,
>>
>> I am trying to build shared libraries on Windows exporting all symbols. This
>> is as an alternative of instrumenting the code with dllimport/dllexport
>> declarations. For this I do build first a static library from which I get
>> all the defined symbols to write a .DEF file which is then used to build the
>> shared library. The CMake code (using version 2.8.3) looks like this:
>>
>> add_library( ${library}-static STATIC ${sources} )
>> add_custom_command( OUTPUT {library}.def COMMAND <using ${library}-static>
>> DEPENDS ${library}-static )
>> add_library(${library} SHARED ${library}.def)
>> target_link_libraries(${library} ${library}-static ${other-libs} )
>> set_target_properties(${library} PROPERTIES LINK_INTERFACE_LIBRARIES
>> ${other-libs})
>>
>> This works just fine when using the nmake generator. The library is created
>> and has all the symbols are exported as desired. But, when using Visual C++
>> 2008 express edition I get the following error message:
>>
>> 1>.\mylib.dir\Debug\mylib.dll.intermediate.manifest : general error
>> c1010070: Failed to load and parse the manifest. The system cannot find the
>> file specified.
>>
>> The problem is that the shared library has been defined without any 'real'
>> source file (only the .def file is declared) and somehow the generated code
>> does not produce the required manifest file. Does anybody see a problem with
>> these kind of constructs? Should it just work from within the IDE?
>> Experimentally I have found a workaround, which consists in adding a dummy
>> source file in the shared library definition.
>>
>> ...
>> file( WRITE ${library}.cpp "// empty file!!!\n" )
>> add_library( ${library} SHARED ${library}.cpp ${library}.def)
>> ...
>>
>>
>> I have also noticed that the dependency of the shared library to the .def
>> file is also missing. This is, newer versions of the .def file does not
>> trigger a re-build of the shared library.
>>
>> -------------------------------------------------------------
>> Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland
>> e-mail: [email protected] tel: +41 22 76 78696
>> fax: +41 22 76 68792 gsm: +41 76 48 70855
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>
-------------------------------------------------------------
Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland
e-mail: [email protected] tel: +41 22 76 78696
fax: +41 22 76 68792 gsm: +41 76 48 70855
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
