How to build & install LCM 1.4.0 on windows using cmake?

[ManaAura]

Dear all,

My main goal is to be able to use lcm-logplayer , lcm-logplayer-gui, and lcm-spy on windows. However, I couldn't get it to work because I am very new to command prompt & cmake. I have tried the the steps in this thread:

https://github.com/lcm-proj/lcm/issues/99

but also couldn't get it to work. I'm stuck on the following error: error 1 CMake Error at C:/Program Files/CMake/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find GLib2 (missing: GLIB2_GLIB_LIBRARY glib) Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) cmake/FindGLib2.cmake:114 (find_package_handle_standard_args) CMakeLists.txt:10 (find_package)

error 2 My cmake-gui doesn't have the variable to let me adjust the path of Glib2

Please help me ~~ Thank you all in advance~

[laran002]

You need to let cmake know where glib is located. In my case I passed the following flags to cmake:

-DGLIB2_GLIBCONFIG_INCLUDE_DIR:PATH=C:/msys64/mingw64/lib/glib-2.0/include \
-DGLIB2_GLIB_INCLUDE_DIR:PATH=C:/msys64/mingw64/include/glib-2.0 \
-DGLIB2_GLIB_LIBRARY:FILEPATH=C:/msys64/mingw64/lib/libglib-2.0.dll.a \
-DGLIB2_GLIB_RUNTIME:FILEPATH=C:/msys64/mingw64/bin/libglib-2.0-0.dll \

[mwoehlke-kitware]

In my case I passed the following flags to cmake: [...]

(Note that you can set these in cmake-gui also. You will need to check the 'advanced' check box to see them, however.)

Alternatively, if you can run cmake-gui from a command prompt in which you have previously set GLIB_PATH (e.g. for @laran002, I believe the correct value would be C:/msys64/mingw64), that may or may not be easier for you.

[mattmunee]

I'm having major problems building LCM for the first time as well. The first set of problems are those mentioned here by ManaAura. I've found that I can get past the CMAKE issues by either specifying the paths in the CMAKE GUI, as described by laran002/mwoehlke-kitware or by replacing the following line in FindGLib2.cmake:

find_library(GLIB2_${VAR}_LIBRARY NAMES ${LIB}-2.0 ${LIB})

with

SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a") find_library(GLIB2_${VAR}_LIBRARY NAMES lib${LIB}-2.0.dll ${LIB})

For reference, my paths link here:

Now I'm facing build problems, using Visual Studio 2017 Professional (x64 Debug). Here's a snippet of the first few errors (there are 307 total):

I can post the entire build output if it helps, but I didn't want to make this post a mile long unless necessary. This is the first time I've ever done anything with msys, so forgive me if I missed something basic. I would greatly appreciate any help.

[mwoehlke-kitware]

Um... .dll.a is just plain strange. I would be inclined to yell at whoever made that package. That said, do you still need to change the find_package line if your added line is instead SET(CMAKE_FIND_LIBRARY_SUFFIXES ".dll.a")?

Adding .a and/or .dll.a to the search suffixes for Windows, and (if it's needed) adding lib to the search prefixes for Windows, both seem like reasonable changes. They might even be worth proposing for CMake itself...

[mattmunee]

I've modified my FindGLib2.cmake to say:

if(WIN32)
    set(CMAKE_FIND_LIBRARY_SUFFIXES ".dll.a")
endif()
find_library(GLIB2_${VAR}_LIBRARY NAMES lib${LIB}-2.0 ${LIB})

instead of the original find_library(GLIB2_${VAR}_LIBRARY NAMES ${LIB}-2.0 ${LIB})

Note that this also added "lib" to the front of "${LIB}-2.0". A change like this should be made in the master repo. I can push, but I'm hesitant since I've never even used LCM and, frankly, have not yet been successful at getting it to build.

Do you have any advice on the build problems from Visual Studio? Should there be a #ifndef _MSC_VER in front of the include statment for unistd.h in emit_go.c? That might solve one of my 300+ problems. For reference, I had no trouble building on a Ubuntu virtual machine.

[mwoehlke-kitware]

Should there be a #ifndef _MSC_VER in front of the include statment for unistd.h in emit_go.c?

Possibly. See also #255.

[mattmunee]

SUCCESS!!!

There were a number of things that needed to be fixed for this to compile.

1. In cmake/FindGLib2.cmake, replace find_library(GLIB2_${VAR}_LIBRARY NAMES ${LIB}-2.0 ${LIB}) with

   if(WIN32)
   set(CMAKE_FIND_LIBRARY_SUFFIXES ".dll.a")
   set(CMAKE_FIND_LIBRARY_PREFIXES "lib")
   endif()
   find_library(GLIB2_${VAR}_LIBRARY NAMES ${LIB}-2.0 ${LIB})

2. In lcm/windows/WinPorting.cpp, include winsock2.h before Mswsock.h, i.e., replace

   #include <Mswsock.h>
   #include <stdio.h>
   #include <winsock2.h>

   with

   #include <stdio.h>
   #include <winsock2.h>
   #include <Mswsock.h>

   This appears to have been screwed up in a recent commit on June 16, 2018.

3. In lcmgen/emit_go.c, replace

   #include <unistd.h>
   #ifdef WIN32
   #define __STDC_FORMAT_MACROS  // Enable integer types
   #endif

   with

   #ifndef WIN32
   #include <unistd.h>
   #endif
   #ifdef WIN32
   #define F_OK 0                /* Test for existence.  */
   #define __STDC_FORMAT_MACROS  // Enable integer types
   #endif

4. In the CMake GUI, uncheck LCM_ENABLE_GO, LCM_ENABLE_LUA, LCM_ENABLE_TESTS. Hopefully I won't need those. I didn't spend too much time troubleshooting.

5. Build in Release. (I don't have the debug Python library python36_d.lib.)

Would you suggest a bug report for these? This is supposed to be a stable release, but it does not work when following the instructions for a clean install.

[kheaactua]

@mattmunee What compiler are you using? I've been trying with msys2 ming2, MSVC2012 and 2017, and haven't really gotten anywhere for days (using master ( 555be4951d351dca39d8ed8b139dce1cbd7d6e04 ) which seems to contain most of the updates above).

With MSVC, it's missing assert.h and dirent.h, when I add those, it's then missing a bunch of stuff from mingw's /usr/include'. I tried copying in all the files it needed but this didn't seem to help, if I addc:/msys64` as a system include path, then it fails with a tonne of errors (presumably macro expansions not going as expected.)

With mingw, I get a bunch of errors from the WinSpecific includes (stdint.h) saying that this can only be build with Visual Studio.

[mattmunee]

@kheaactua, Not being in front of my computer, I can't be entirely sure what's causing your issue. I used VS2017 x64 (to compile) and MSYS2 x64. One issue may be your path. You shouldn't add C:\msys64. You should add C:\msys64\mingw64\lib and C:\msys64\mingw64\bin. Hopefully that's all you're missing. I wrote up some instructions for my colleagues, tested on a clean VM. If that doesn't help, I could send them to you.

[kheaactua]

Hi @mattmunee, instructions would be fantastic! I'd really appreciate that.

I didn't actually add anything to my path, but that's because I didn't get to any linking step, I kept getting caught with include issues. I'm also going to check my VS2017 install to see if there is more I can install (it's suppose to have assert.h), for VS2013 though I'm not sure what to do.

[mattmunee]

@kheaactua This attachment was modified from a larger document. The java and python sections may not be relevant. I just don't recall. (Certainly are if you want to use LCM with java or python.) Building LCM.pdf

[kheaactua]

@mattmunee I'm dealing with a more emergency problem right now, but will try those instructions out ASAP. Thanks!!

[kheaactua]

@mattmunee I still have the same include issues. I'm going to try setting up a fresh Windows VM, and go through the instructions you sent again line by line. Thanks for the help.

[mattmunee]

@kheaactua Looks like assert.h and dirent.h are in C:\msys64\mingw64\x86_64-w64-mingw32\include. It appears that GLib is dependent on those files. Did you follow the steps for GLib? Any indication of problems when you ran CMake?