[Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

[Eran Ifrah via lldb-commits]

eran.ifrah added a comment.

Spoke too soon, the hack into `CMakeLists.txt` is still needed
Passing ` -mbig-obj` crashes `ld.exe`  (although it crashes in a much later stage, at about 77% in the build)


================
Comment at: CMakeLists.txt:3-5
@@ -2,1 +2,5 @@
 
+if(MINGW_DEBUG)
+    # force debugging info into lldb sources
+    message("-- Building LLDB in Debug mode")
+    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g -O0")
----------------
zturner wrote:
> Can you try the /bigobj solution proposed by Pavel?  which specific object file fails to link, is it an LLDB obj or a clang obj?  Because as Pavel mentions clang has had this problem before, so maybe you just need to specify /bigobj for MinGW in the clang library and not in LLDB?
I fixed the top level `CMakeLists.txt` (LLVM one)

================
Comment at: cmake/modules/LLDBConfig.cmake:225-236
@@ -224,3 +224,4 @@
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
 check_cxx_compiler_flag("-Wno-deprecated-register"
                         CXX_SUPPORTS_NO_DEPRECATED_REGISTER)
 if (CXX_SUPPORTS_NO_DEPRECATED_REGISTER)

@@ -232,4 +233,5 @@
 if (CXX_SUPPORTS_NO_VLA_EXTENSION)
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-vla-extension")
 endif ()
+endif()
 
----------------
zturner wrote:
> Still indentation problems here.
Are you calling the missing space before the opening paren an indentation problem? otherwise, I think I am missing something here
its 2 spaces indented

================
Comment at: source/API/CMakeLists.txt:74-85
@@ -73,6 +73,14 @@
 # want every single library taking a dependency on the script interpreters.
+if(MINGW)
 target_link_libraries(liblldb PRIVATE
   lldbPluginScriptInterpreterNone
   lldbPluginScriptInterpreterPython
+    Dbghelp # Needed for MiniDumpWriteDump
   )
+else()
+  target_link_libraries(liblldb PRIVATE
+    lldbPluginScriptInterpreterNone
+    lldbPluginScriptInterpreterPython
+    )
+endif()
 
----------------
zturner wrote:
> How about this instead:
> 
>     target_link_libraries(liblldb PRIVATE
>       lldbPluginScriptInterpreterNone
>       lldbPluginScriptInterpreterPython)
> 
>     if(MINGW)
>       target_link_libraries(liblldb PRIVATE Dbghelp)
>     endif()
> 
This was my first try, however, this yields a warning in cmake 3.0 and later: target_link_libraries can only be used once per target

================
Comment at: source/Plugins/Process/Windows/Live/DebuggerThread.cpp:380-383
@@ -379,5 +379,6 @@
         {
+            DWORD dwPidToDetach = m_pid_to_detach;
             WINLOG_IFANY(WINDOWS_LOG_EVENT | WINDOWS_LOG_EXCEPTION | WINDOWS_LOG_PROCESS,
                             "Breakpoint exception is cue to detach from process 0x%x",
-                            m_pid_to_detach);
+                            dwPidToDetach);
             ::DebugActiveProcessStop(m_pid_to_detach);
----------------
zturner wrote:
> Can this line be reverted?  I'm not sure what the point of saving it into a temp variable is.
No, this change was done on purpose. Removing the fix I added, will trigger this error from the compiler:
```
use of deleted function
```


================
Comment at: tools/argdumper/CMakeLists.txt:6-8
@@ +5,5 @@
+if(MINGW)
+    # link directly against the dll file
+    add_dependencies(lldb-argdumper liblldb)
+    target_link_libraries(lldb-argdumper -L"${CMAKE_BINARY_DIR}/bin" -llldb)
+else()
----------------
zturner wrote:
> 2 space indent for CMake, not 4.  Also the `target_link_libraries in the `else()` branch should be indented.  As Pavel says, I'm not sure why this is needed, but I can't really argue against it because I don't know much about MinGW
This is needed because otherwise, you will get multiple definitions for many symbols - this is the side effect when linking with a `.dll.a` in MinGW systems when you don't really need to do this, since you can link directly to `.dll` file

================
Comment at: tools/driver/CMakeLists.txt:20
@@ -19,1 +19,3 @@
 
+if(MINGW)
+    # link directly against the dll file
----------------
Same answer


http://reviews.llvm.org/D18519