[CMake] Can't get CMake to use an import library generated from a MODULE target

[Hendrik Sattler]

Am 18. Februar 2016 09:44:35 MEZ, schrieb Sam Habiel <sam.habiel at gmail.com>:
>Rather than email one of the folks at Kitware, I decided to join the
>CMake mailing list... Hello all for those who remember me.
>
>I apologize for the long email.
>
>A few of us have been trying to port GT.M
>(https://www.fisglobal.com/Solutions/Services/Database-Engine) to
>Cygwin, 1. to get it running on Windows 2. as an exercise to prepare
>for harder ports, the Raspberry Pi being the holy grail here. That's
>the background.

And then you try Cygwin? That's about as close to Rasberry Pi on Linux as bare Windows itself. Especially your problem from below is only caused by Windows.

>The problem we are having is familiar to many; but not initially to
>me. See the heading "Shared libraries with Windows/MinGW" in this
>article:
>http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.
>
>CMakeLists.txt:
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt
>
>The error:
>[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
>In function `gc_load_gtmshr_symbols':
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined
>reference to `gtm_malloc'
>/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined
>reference to `gtm_free'
>collect2: error: ld returned 1 exit status
>CMakeFiles

Looking at these locations, it is clear that you store a reference to a function, there. The reference cannot be resolved but for a Windows DLL all references must be resolved at link time.

/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe
>for target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
>make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
>CMakeFiles/Makefile2:891: recipe for target
>'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
>make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error
>2
>Makefile:116: recipe for target 'all' failed
>make: *** [all] Error 2
>
>Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
>/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
>-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG
>-shared -Wl,--enable-auto-import -o
>plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
>-Wl,--major-image-version,0,--minor-image-version,0
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
>CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
>-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a
>
>What is missing is that there needs to be either a link to
>cyggtmshr.dll, or a way for CMake to know to generate a
>libgtmshr_import.lib and add it to the link command.
 
Or don't use a direct reference in the code but use the module that provides those functions at runtime like you designed it to. You can use local wrapper functions to do so.

>So here is what I tried:
>1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
>If I do that, it doesn't seem to generate the import library; but it
>sure does generate an export header, which I don't need. Here it is:
>include(GenerateExportHeader)
>generate_export_header(libgtmshr
>    BASE_NAME libgtmshr
>    EXPORT_MACRO_NAME libgtmshr_EXPORTS
>    EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
>    STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
>
>2. Explicitly adding a libgtmshr as a dependency on line
>https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
>but only for Cygwin. I get this error message:
>CMake Error at CMakeLists.txt:542 (target_link_libraries):
>Target "libgtmshr" of type MODULE_LIBRARY may not be linked into
>another
>target.  One may link only to STATIC or SHARED libraries, or to
>executables
>  with the ENABLE_EXPORTS property set.
>
>The GT.M developer familiar with CMake suggested me to use LINK_FLAGS
>and have CMake use the file by us hardcoding it in; which I am okay
>doing, but I thought I would check to see if there is an alternative
>way of doing this.
>
>I also tried the suggestions here:
>"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/"
>to no avail.
>
>Last, but not least:
>
>sam at horus ~/fis-gtm-cygwin
>$ cmake --version
>cmake version 3.4.3
>
>CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
>sam at horus ~/fis-gtm-cygwin
>$ uname -a
>CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin