Am 18. Februar 2016 09:44:35 MEZ, schrieb Sam Habiel <sam.hab...@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@horus ~/fis-gtm-cygwin >$ cmake --version >cmake version 3.4.3 > >CMake suite maintained and supported by Kitware (kitware.com/cmake). > >sam@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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake