<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 1, 2014 at 10:57 AM, Deepak Panickal <span dir="ltr"><<a href="mailto:deepak@codeplay.com" target="_blank">deepak@codeplay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Modified: lldb/trunk/include/lldb/lldb-python.h<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-python.h?rev=212111&r1=212110&r2=212111&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-python.h?rev=212111&r1=212110&r2=212111&view=diff</a><br>
==============================================================================<br>
--- lldb/trunk/include/lldb/lldb-python.h (original)<br>
+++ lldb/trunk/include/lldb/lldb-python.h Tue Jul 1 12:57:19 2014<br>
@@ -13,22 +13,46 @@<br>
// Python.h needs to be included before any system headers in order to avoid redefinition of macros<br>
<br>
#ifdef LLDB_DISABLE_PYTHON<br>
-<br>
// Python is disabled in this build<br>
-<br>
#else<br>
+ // If this is a visual studio build<br>
+ #if defined( _MSC_VER )<br>
+ // Special case for debug build since python unfortunately<br>
+ // adds library to the linker path through a #pragma directive<br>
+ #if defined( _DEBUG )<br>
+ // Python forces a header link to python27_d.lib when building debug.<br>
+ // To get around this (because most python packages for Windows<br>
+ // don't come with debug python libraries), we undefine _DEBUG, include<br>
+ // python.h and then restore _DEBUG.<br>
+<br>
+ // The problem with this is that any system level headers included from<br>
+ // python.h were also effectively included in 'release' mode when we undefined<br>
+ // _DEBUG. To work around this we include headers that python includes<br>
+ // before undefining _DEBUG.<br>
+ # include <stdlib.h><br>
+ // Undefine to force python to link against the release distro<br>
+ # undef _DEBUG<br>
+ # include <Python.h><br>
+ # define _DEBUG<br>
+<br>
+ #else<br>
+ #include <Python.h><br>
+ #endif<br>
+<br>
+ #else<br>
+ #if defined(__linux__)<br>
+ // features.h will define _POSIX_C_SOURCE if _GNU_SOURCE is defined. This value<br>
+ // may be different from the value that Python defines it to be which results<br>
+ // in a warning. Undefine _POSIX_C_SOURCE before including Python.h The same<br>
+ // holds for _XOPEN_SOURCE.<br>
+ #undef _POSIX_C_SOURCE<br>
+ #undef _XOPEN_SOURCE<br>
+ #endif<br></blockquote><div>What about specifying /NODEFAULTLIB:python27_d.lib and then manually link against python27.lib instead? Seems like a better fix.</div><div><br></div><div>Another problem with this header is that pymath.h on Windows does a check for HAVE_ROUND, and if it's not found it provides its own implementation of round(). VS2013 and above provide this function, however. Could you add a line to the CMake along the lines of:</div>
<div><br></div><div>if ((NOT MSVC) OR MSVC12)</div><div> add_definitions( -DHAVE_ROUND )</div><div>endif()</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Modified: lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp?rev=212111&r1=212110&r2=212111&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp?rev=212111&r1=212110&r2=212111&view=diff</a><br>
==============================================================================<br>
--- lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp (original)<br>
+++ lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp Tue Jul 1 12:57:19 2014<br>
@@ -589,7 +589,12 @@ ScriptInterpreterPython::ExecuteOneLine<br>
input_file_sp = debugger.GetInputFile();<br>
// Set output to a temporary file so we can forward the results on to the result object<br>
<br>
+#ifdef _MSC_VER<br>
+ // pipe is not supported on windows so default to a fail condition<br>
+ int err = 1;<br>
+#else<br>
int err = pipe(pipe_fds);<br>
+#endif<br>
if (err == 0)<br>
{<br>
std::unique_ptr<ConnectionFileDescriptor> conn_ap(new ConnectionFileDescriptor(pipe_fds[0], true));<br></blockquote><div>Windows actually does support pipe, it's just called _pipe and has a slightly different signature. But I think you can make it work.</div>
<div><br></div><div><a href="http://msdn.microsoft.com/en-us/library/edze9h7e.aspx">http://msdn.microsoft.com/en-us/library/edze9h7e.aspx</a></div><div><br></div><div>One more issue is that ScriptInterpreter::TerminateInterpreter() calls ScriptInterpreterPython::TerminateInterpreter(), which is not defined, so the function calls itself, leading to an infinite recursion warning. Can we fix this warning?<br>
</div></div></div></div>