AW: [CMake] Weird DLL_EXPORT disables creation of .lib-files with Visual C++ .NET 2003

wedekind wedekind at caesar.de
Wed Jun 29 10:22:07 EDT 2005


Hello Brad,

thanks for your quick response! I have checked the sources and you are
right: there are (some) export definitions  that do not fit the cmake
"target-name_EXPORTS"-pattern for export definitions.

Changing the source code might be an option, but it is good to know how to
redefine cmakes export-macro definition... But I have some problems with
this redefinition, here is an example of the beginnig of a
CMakeLists.txt-file:

PROJECT(JCore)

SET_TARGET_PROPERTIES(JCore PROPERTIES DEFINE_SYMBOL JCORE_DLL_EXPORT)

...

In this case JCORE_DLL_EXPORT is my own export-macro definition. Is the
snippet above correct? This preprocessor definition defined by
SET_TARGET_PROPERTIES simply does not appear in my generated project
files... 

Thanks

Marco


-----Ursprüngliche Nachricht-----
Von: Brad King [mailto:brad.king at kitware.com] 
Gesendet: Mittwoch, 29. Juni 2005 15:54
An: wedekind
Cc: cmake at cmake.org
Betreff: Re: [CMake] Weird DLL_EXPORT disables creation of .lib-files with
Visual C++ .NET 2003

wedekind wrote:
> I have created a CMakeLists.txt for a Visual C++ .NET 2003 project, I 
> am using Cmake 2.0.6. My problem is, that the resulting vcproj-file 
> does not create a .lib-file for the project, just the .dll-file is 
> created. In order to link the created dll with my other projects I 
> need the lib-file. No it gets weird... If I change a preprocessor 
> definition from JCore_EXPORTS to JCORE_DLL_EXPORT (note the change in 
> case too) it creates the lib file. But I doubt that changing this 
> preprocessor definition alone is the solution because I also have 
> (very similar) projects that create lib-files without this 
> *_DLL_EXPORT-definition, they only have the cmake-created
*_EXPORTS-definition (without DLL in it)!

When a dll is created it is up to the source code to put
__declspec(dllexport) in the right places to tell the linker to export the
symbols.  Those exports are then stored in the .lib file.  If there are no
exports then no one can link to the library (it can only be loaded
dynamically with a LoadLibrary call) so there is no reason to have a .lib
file.

When a dll is used it is up to the source code to put
__declspec(dllimport) in the right places to tell the linker that the symbol
will come from a dll.  Since this has to be in the same place the typical
solution is to use code like this:

#ifdef MYLIB_EXPORTS
# define MYLIB_EXPORT __declspec(dllexport)  /* building the lib */ #else #
define MYLIB_EXPORT __declspec(dllimport)  /* building user code */ #endif

Then the MYLIB_EXPORT macro is used in the right places in the source code.
In order to support this the build system must define "MYLIB_EXPORTS" when
building the sources in the library and not define it elsewhere.  CMake
provides automatic support for this by defining a "target-name_EXPORTS"
macro for sources being placed in a shared library "target-name".

You will have to check that the code uses the same name for MYLIB_EXPORTS
that CMake is defining.  If changing the code is not an option and it looks
for a different macro than the one CMake provides you can tell CMake to
provide a differnent one like this:

SET_TARGET_PROPERTIES(MYLIB PROPERTIES
   DEFINE_SYMBOL mylib_custom_EXPORTS_macro
)

-Brad




More information about the CMake mailing list