lldb python support

[cristianadam]

Qt Creator requires python support from gdb / lldb debugger.

It would be great to have a fully toolchain on Windows 😄

[mstorsjo]

Out of curiousity - which way does Qt Creator integrate with the debugger when it requires python support?

I clearly see the value in better being able to integrate this toolchain with IDEs, but including python here (where I'm crosscompiling everything from scratch for all 4 architectures I'm supporting) is a bit out of scope at the moment - I'm not able to spend effort on that in the near future, unfortunately.

[cristianadam]

Out of curiousity - which way does Qt Creator integrate with the debugger when it requires python support?

All data display, and partially operations like stepping use the python interface provided by GDB and LLDB.

I clearly see the value in better being able to integrate this toolchain with IDEs, but including python here (where I'm crosscompiling everything from scratch for all 4 architectures I'm supporting) is a bit out of scope at the moment - I'm not able to spend effort on that in the near future, unfortunately.

I can see how this can be a problem. Kitware has at their https://open.cdash.org a project:

CPython	This is a replacement buildsystem for Python. The existing (autotools based) buildsystem for Python is overcomplicated and makes cross-compiling very difficult.

This would mean that Python could be compiled the same way as LLVM/Clang, with CMake 😄

The code is hosted at https://github.com/python-cmake-buildsystem/python-cmake-buildsystem

[RussellHaley]

It appears that KDevelop also uses python. @longnguyen2004 passed on your llvm 11 test build with lldb-mi and I ran it with KDevelop 5.5.0. This was the error in the console:

lldb-mi 
error: module importing failed: This script interpreter does not support importing modules.
error: 'settings set' takes more arguments
error: 'settings set' takes more arguments
error: 'settings set' takes more arguments

I've also put in a question with the KDevelop mailing list.

[mstorsjo]

It appears that KDevelop also uses python. @longnguyen2004 passed on your llvm 11 test build with lldb-mi and I ran it with KDevelop 5.5.0. This was the error in the console:

lldb-mi 
error: module importing failed: This script interpreter does not support importing modules.
error: 'settings set' takes more arguments
error: 'settings set' takes more arguments
error: 'settings set' takes more arguments

I've also put in a question with the KDevelop mailing list.

Hmm, ok, that's a shame. I wonder if there's any other potential use of lldb-mi in the current form then... IIRC Qt Creator also could use it, maybe I need to try to set that up and see if I could make them work together, or if that one also requires a python-capable lldb.

[mstorsjo]

Hmm, ok, that's a shame. I wonder if there's any other potential use of lldb-mi in the current form then... IIRC Qt Creator also could use it, maybe I need to try to set that up and see if I could make them work together, or if that one also requires a python-capable lldb.

Nevermind, it was already stated at the top of this thread that it does indeed require a python-capable lldb.

[RussellHaley]

I've been mucking with the python-cmake-build. It builds natively on FreeBSD. I created a mingw.cmake cross file for building with llvm-mingw. My open issue is here: https://github.com/python-cmake-buildsystem/python-cmake-buildsystem/issues/274

[RussellHaley]

Hi, I managed to get this to cross compile python 3.6.7 in Ubuntu using standard mingw-w64. I had to make the follow changes:

• I created a mingw cross build toolchain file for x86_64
• The README indicates patches that need to be manually applied. Those patches are for Python 2.6. I should go back and check the contents to see if they are similar to my changes.
• Had to patch the python-cmake-buildsystem files (cmake patch and an h file included for mingw)
• Patched the python source code. There were some "case issues" in some includes and I patched some warnings that were hiding issues (could have turned off warnings but that seemed unwise)
• I had to work around a tool that is built for the target platform and then used in the build process.

The trickiest part is the third item, the work around. During the build process a tool called _freeze_importlib(.exe) is built. _freeze_importlib(.exe) assembles two header files: Python-3.6.7/Python/importlib.h and Python-3.6.7/Python/importlib_external.h. The cmake system is set up to run _freese_importlib in a "target emulator". I chose instead to build for Linux first, then run the host version manually and copy the files into my build. Obviously, that isn't very portable.

Still outstanding:

• I haven't tested the build yet.
• I couldn't get ALL_PROCESSOR_GROUPS define to work which indicates I am using the wrong value for _WIN32_WINNT. You may note below an attempt to patch that unsucessfully in cmake/config-mingw/pyconfig.h. I had to hard coded 0xffff instead. (see https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getmaximumprocessorcount)
• I noted an implicit declaration in the build that seems to also indicate I am using the wrong _WIN32_WINNT version: ''' ../Python-3.6.7/Python/pytime.c:676:13: warning: implicit declaration of function ‘GetTickCount64’; did you mean ‘GetTickCount’? [-Wimplicit-function-declaration] 676 | ticks = GetTickCount64(); | ^~~~~~ | GetTickCount '''

The patches are just hacks at the moment but I am presenting my work in progress here in case you have any input? I will be presenting my findings to the python-cmake-build team later this week (Jan 4) .

Regards.

python-cmake-buildsystem patches:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4118010..213adb3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -386,12 +386,14 @@ if(UNIX)
     configure_file(cmake/config-unix/pyconfig.h.in
                    ${PYCONFIG_BUILD_DIR}/pyconfig.h)
 elseif(WIN32)
-    set(PYCONFIG_BUILD_DIR ${SRC_DIR}/PC) # In a windows build tree, 'pyconfig.h' is NOT required to
+
+   if(MINGW)
+      set(PYCONFIG_BUILD_DIR cmake/config-mingw)
+    else()
+       set(PYCONFIG_BUILD_DIR ${SRC_DIR}/PC) # In a windows build tree, 'pyconfig.h' is NOT required to
                                           # live along side the python executable.
                                           # See function '_init_posix()' and '_init_non_posix()'
                                           # in 'Lib/sysconfig.py'
-    if(MINGW)
-      set(PYCONFIG_BUILD_DIR cmake/config-mingw)
     endif()
 endif()

diff --git a/cmake/config-mingw/pyconfig.h b/cmake/config-mingw/pyconfig.h
index 5af0378..3c037c4 100644
--- a/cmake/config-mingw/pyconfig.h
+++ b/cmake/config-mingw/pyconfig.h
@@ -89,15 +89,18 @@ WIN32 is still required for the locale module.
 #  define Py_WINVER _WIN32_WINNT_WINXP
 #  define Py_NTDDI NTDDI_WINXP
 #else
-/* Python 2.6+ requires Windows 2000 or greater */
+/* Python 3.6+ requires Windows 7 or greater */
 #  ifdef _WIN32_WINNT_WIN2K
+#    warning "got here" 
 #    define Py_WINVER _WIN32_WINNT_WIN2K
 #  else
-#    define Py_WINVER 0x0500
+#   warning "nope went there instead"
+#    define Py_WINVER 0x0601
 #  endif
 #  define Py_NTDDI NTDDI_WIN2KSP4
 #endif

+
 /* We only set these values when building Python - we don't want to force
    these values on extensions, as that will affect the prototypes and
    structures exposed in the Windows headers. Even when building Python, we
@@ -121,9 +124,9 @@ WIN32 is still required for the locale module.
 #define HAVE_SSIZE_T 1

 #include <float.h>
-#define Py_IS_NAN _isnan
-#define Py_IS_INFINITY(X) (!_finite(X) && !_isnan(X))
-#define Py_IS_FINITE(X) _finite(X)
+#define Py_IS_NAN _isnanf
+#define Py_IS_INFINITY(X) (!_finitef(X) && !_isnanf(X))
+#define Py_IS_FINITE(X) _finitef(X)
 #define copysign _copysign

 #include <basetsd.h>
@@ -224,39 +227,39 @@ Py_NO_ENABLE_SHARED to find out.  Also support MS_NO_COREDLL for b/w compat */

 /* define signed and unsigned exact-width 32-bit and 64-bit types, used in the
    implementation of Python long integers. */
-#ifndef PY_UINT32_T
-#if SIZEOF_INT == 4
-#define HAVE_UINT32_T 1
-#define PY_UINT32_T unsigned int
-#elif SIZEOF_LONG == 4
-#define HAVE_UINT32_T 1
-#define PY_UINT32_T unsigned long
-#endif
-#endif
-
-#ifndef PY_UINT64_T
-#if SIZEOF_LONG_LONG == 8
-#define HAVE_UINT64_T 1
-#define PY_UINT64_T unsigned PY_LONG_LONG
-#endif
-#endif
-
-#ifndef PY_INT32_T
-#if SIZEOF_INT == 4
-#define HAVE_INT32_T 1
-#define PY_INT32_T int
-#elif SIZEOF_LONG == 4
-#define HAVE_INT32_T 1
-#define PY_INT32_T long
-#endif
-#endif
-
-#ifndef PY_INT64_T
-#if SIZEOF_LONG_LONG == 8
-#define HAVE_INT64_T 1
-#define PY_INT64_T PY_LONG_LONG
-#endif
-#endif
+//~ #ifndef PY_UINT32_T
+//~ #if SIZEOF_INT == 4
+//~ #define HAVE_UINT32_T 1
+//~ #define PY_UINT32_T unsigned int
+//~ #elif SIZEOF_LONG == 4
+//~ #define HAVE_UINT32_T 1
+//~ #define PY_UINT32_T unsigned long
+//~ #endif
+//~ #endif
+
+//~ #ifndef PY_UINT64_T
+//~ #if SIZEOF_LONG_LONG == 8
+//~ #define HAVE_UINT64_T 1
+//~ #define PY_UINT64_T unsigned PY_LONG_LONG
+//~ #endif
+//~ #endif
+
+//~ #ifndef PY_INT32_T
+//~ #if SIZEOF_INT == 4
+//~ #define HAVE_INT32_T 1
+//~ #define PY_INT32_T int
+//~ #elif SIZEOF_LONG == 4
+//~ #define HAVE_INT32_T 1
+//~ #define PY_INT32_T long
+//~ #endif
+//~ #endif
+
+//~ #ifndef PY_INT64_T
+//~ #if SIZEOF_LONG_LONG == 8
+//~ #define HAVE_INT64_T 1
+//~ #define PY_INT64_T PY_LONG_LONG
+//~ #endif
+//~ #endif

 /* Fairly standard from here! */

@@ -382,7 +385,7 @@ Py_NO_ENABLE_SHARED to find out.  Also support MS_NO_COREDLL for b/w compat */

 /* Define as the size of the unicode type. */
 /* This is enough for unicodeobject.h to do the "right thing" on Windows. */
-#define Py_UNICODE_SIZE 2
+//~ #define Py_UNICODE_SIZE 2

 /* Use Python's own small-block memory-allocator. */
 #define WITH_PYMALLOC 1
diff --git a/cmake/libpython/CMakeLists.txt b/cmake/libpython/CMakeLists.txt
index 6b183b2..a1c79f1 100644
--- a/cmake/libpython/CMakeLists.txt
+++ b/cmake/libpython/CMakeLists.txt
@@ -394,40 +394,42 @@ endif()
 set(LIBPYTHON_FROZEN_SOURCES )
 if(IS_PY3)

+# RH:2021-01-02
+#IF NOT CROSS BUILDING THEN BUILD FREEZE_IMPORTLIBS. ELSE USE HOST VARIANT
 # Build _freeze_importlib executable
-add_executable(_freeze_importlib
-  ${SRC_DIR}/Programs/_freeze_importlib.c
-  ${LIBPYTHON_OMIT_FROZEN_SOURCES}
-  )
-target_link_libraries(_freeze_importlib ${LIBPYTHON_TARGET_LIBRARIES})
-if(builtin_compile_definitions_without_py_limited_api)
-  target_compile_definitions(_freeze_importlib PUBLIC ${builtin_compile_definitions_without_py_limited_api})
-endif()
-
-# Freeze modules
-set(LIBPYTHON_FROZEN_SOURCES
-  ${SRC_DIR}/Python/importlib_external.h
-  ${SRC_DIR}/Python/importlib.h
-)
-add_custom_command(
-  OUTPUT ${LIBPYTHON_FROZEN_SOURCES}
-  COMMAND
-    ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:_freeze_importlib>
-      ${SRC_DIR}/Lib/importlib/_bootstrap_external.py
-      ${SRC_DIR}/Python/importlib_external.h
-  COMMAND
-    ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:_freeze_importlib>
-      ${SRC_DIR}/Lib/importlib/_bootstrap.py
-      ${SRC_DIR}/Python/importlib.h
-  DEPENDS
-    _freeze_importlib
-    ${SRC_DIR}/Lib/importlib/_bootstrap_external.py
-    ${SRC_DIR}/Lib/importlib/_bootstrap.py
-)
-
-# This is a convenience target allowing to regenerate
-# the frozen sources.
-add_custom_target(freeze_modules DEPENDS ${LIBPYTHON_FROZEN_SOURCES})
+#~ add_executable(_freeze_importlib
+  #~ ${SRC_DIR}/Programs/_freeze_importlib.c
+  #~ ${LIBPYTHON_OMIT_FROZEN_SOURCES}
+  #~ )
+#~ target_link_libraries(_freeze_importlib ${LIBPYTHON_TARGET_LIBRARIES})
+#~ if(builtin_compile_definitions_without_py_limited_api)
+  #~ target_compile_definitions(_freeze_importlib PUBLIC ${builtin_compile_definitions_without_py_limited_api})
+#~ endif()
+
+#~ # Freeze modules
+#~ set(LIBPYTHON_FROZEN_SOURCES
+  #~ ${SRC_DIR}/Python/importlib_external.h
+  #~ ${SRC_DIR}/Python/importlib.h
+#~ )
+#~ add_custom_command(
+  #~ OUTPUT ${LIBPYTHON_FROZEN_SOURCES}
+  #~ COMMAND
+    #~ ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:_freeze_importlib>
+      #~ ${SRC_DIR}/Lib/importlib/_bootstrap_external.py
+      #~ ${SRC_DIR}/Python/importlib_external.h
+  #~ COMMAND
+    #~ ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:_freeze_importlib>
+      #~ ${SRC_DIR}/Lib/importlib/_bootstrap.py
+      #~ ${SRC_DIR}/Python/importlib.h
+  #~ DEPENDS
+    #~ _freeze_importlib
+    #~ ${SRC_DIR}/Lib/importlib/_bootstrap_external.py
+    #~ ${SRC_DIR}/Lib/importlib/_bootstrap.py
+#~ )
+
+#~ # This is a convenience target allowing to regenerate
+#~ # the frozen sources.
+#~ add_custom_target(freeze_modules DEPENDS ${LIBPYTHON_FROZEN_SOURCES})

 endif()

Python-3.6.7 patches

Only in Python-3.6.7_rh/Include: fficonfig.h
diff -ru Python-3.6.7/Include/pylifecycle.h Python-3.6.7_rh/Include/pylifecycle.h
--- Python-3.6.7/Include/pylifecycle.h  2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Include/pylifecycle.h   2021-01-03 02:38:03.813756479 -0500
@@ -60,7 +60,7 @@
 PyAPI_FUNC(wchar_t *) Py_GetPath(void);
 PyAPI_FUNC(void)      Py_SetPath(const wchar_t *);
 #ifdef MS_WINDOWS
-int _Py_CheckPython3();
+PyAPI_FUNC(int) _Py_CheckPython3(void);
 #endif

 /* In their own files */
diff -ru Python-3.6.7/Include/unicodeobject.h Python-3.6.7_rh/Include/unicodeobject.h
--- Python-3.6.7/Include/unicodeobject.h    2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Include/unicodeobject.h 2021-01-02 20:03:22.480796914 -0500
@@ -64,6 +64,8 @@
 /* Python 3.x requires unicode */
 #define Py_USING_UNICODE

+#define SIZEOF_WCHAR_T 2
+
 #ifndef SIZEOF_WCHAR_T
 #error Must define SIZEOF_WCHAR_T
 #endif
diff -ru Python-3.6.7/Modules/posixmodule.c Python-3.6.7_rh/Modules/posixmodule.c
--- Python-3.6.7/Modules/posixmodule.c  2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Modules/posixmodule.c   2021-01-03 02:46:48.538559304 -0500
@@ -164,7 +164,7 @@
 #define HAVE_SYSTEM     1
 #include <process.h>
 #else
-#ifdef _MSC_VER         /* Microsoft compiler */
+#ifdef _WIN32         /* Microsoft compiler */
 #define HAVE_GETPPID    1
 #define HAVE_GETLOGIN   1
 #define HAVE_SPAWNV     1
@@ -204,7 +204,7 @@
 [clinic start generated code]*/
 /*[clinic end generated code: output=da39a3ee5e6b4b0d input=94a0f0f978acae17]*/

-#ifndef _MSC_VER
+#ifndef _WIN32

 #if defined(__sgi)&&_COMPILER_VERSION>=700
 /* declare ctermid_r if compiling with MIPSPro 7.x in ANSI C mode
@@ -296,7 +296,7 @@
 #endif
 #endif

-#ifdef _MSC_VER
+#ifdef _WIN32
 #ifdef HAVE_DIRECT_H
 #include <direct.h>
 #endif
@@ -406,7 +406,7 @@

 #ifdef MS_WINDOWS
 static int
-win32_warn_bytes_api()
+win32_warn_bytes_api(void)
 {
     return PyErr_WarnEx(PyExc_DeprecationWarning,
         "The Windows bytes API has been deprecated, "
@@ -6297,7 +6297,7 @@
 #include <tlhelp32.h>

 static PyObject*
-win32_getppid()
+win32_getppid(void)
 {
     HANDLE snapshot;
     pid_t mypid;
@@ -10440,7 +10440,7 @@
 static HINSTANCE (CALLBACK *Py_ShellExecuteW)(HWND, LPCWSTR, LPCWSTR, LPCWSTR,
                                               LPCWSTR, INT);
 static int
-check_ShellExecute()
+check_ShellExecute(void)
 {
     HINSTANCE hShell32;

@@ -11074,7 +11074,8 @@
     *(FARPROC*)&_GetMaximumProcessorCount = GetProcAddress(hKernel32,
         "GetMaximumProcessorCount");
     if (_GetMaximumProcessorCount != NULL) {
-        ncpu = _GetMaximumProcessorCount(ALL_PROCESSOR_GROUPS);
+        //~ ncpu = _GetMaximumProcessorCount(ALL_PROCESSOR_GROUPS);
+        ncpu = _GetMaximumProcessorCount(0xffff);
     }
     else {
         SYSTEM_INFO sysinfo;
@@ -12443,7 +12444,7 @@

 #if defined(HAVE_SYMLINK) && defined(MS_WINDOWS)
 static int
-enable_symlink()
+enable_symlink(void)
 {
     HANDLE tok;
     TOKEN_PRIVILEGES tok_priv;
diff -ru Python-3.6.7/Modules/socketmodule.h Python-3.6.7_rh/Modules/socketmodule.h
--- Python-3.6.7/Modules/socketmodule.h 2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Modules/socketmodule.h  2021-01-02 20:15:15.227340788 -0500
@@ -28,7 +28,7 @@
  * I use SIO_GET_MULTICAST_FILTER to detect a decent SDK.
  */
 # ifdef SIO_GET_MULTICAST_FILTER
-#  include <MSTcpIP.h> /* for SIO_RCVALL */
+#  include <mstcpip.h> /* for SIO_RCVALL */
 #  define HAVE_ADDRINFO
 #  define HAVE_SOCKADDR_STORAGE
 #  define HAVE_GETADDRINFO
diff -ru Python-3.6.7/Modules/_winapi.c Python-3.6.7_rh/Modules/_winapi.c
--- Python-3.6.7/Modules/_winapi.c  2021-01-04 00:45:22.357716309 -0500
+++ Python-3.6.7_rh/Modules/_winapi.c   2021-01-03 02:43:55.069889480 -0500
@@ -68,7 +68,7 @@
 static BOOL (CALLBACK *Py_CancelIoEx)(HANDLE, LPOVERLAPPED);

 static int
-check_CancelIoEx()
+check_CancelIoEx(void)
 {
     if (has_CancelIoEx == -1)
     {
diff -ru Python-3.6.7/PC/getpathp.c Python-3.6.7_rh/PC/getpathp.c
--- Python-3.6.7/PC/getpathp.c  2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/PC/getpathp.c   2021-01-03 02:37:55.965604673 -0500
@@ -88,7 +88,7 @@
 #endif

 #include <windows.h>
-#include <Shlwapi.h>
+#include <shlwapi.h>

 #ifdef HAVE_SYS_TYPES_H
 #include <sys/types.h>
@@ -968,7 +968,7 @@
 static int python3_checked = 0;
 static HANDLE hPython3;
 int
-_Py_CheckPython3()
+_Py_CheckPython3(void)
 {
     wchar_t py3path[MAXPATHLEN+1];
     wchar_t *s;
diff -ru Python-3.6.7/Programs/python.c Python-3.6.7_rh/Programs/python.c
--- Python-3.6.7/Programs/python.c  2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Programs/python.c   2021-01-03 02:23:29.001256996 -0500
@@ -9,9 +9,9 @@

 #ifdef MS_WINDOWS
 int
-wmain(int argc, wchar_t **argv)
+main(int argc, char **argv)
 {
-    return Py_Main(argc, argv);
+    return Py_Main(argc, (wchar_t **)argv);
 }
 #else

diff -ru Python-3.6.7/Python/thread_nt.h Python-3.6.7_rh/Python/thread_nt.h
--- Python-3.6.7/Python/thread_nt.h 2018-10-20 01:24:09.000000000 -0400
+++ Python-3.6.7_rh/Python/thread_nt.h  2021-01-03 02:42:53.437474074 -0500
@@ -32,7 +32,7 @@
 typedef NRMUTEX *PNRMUTEX;

 PNRMUTEX
-AllocNonRecursiveMutex()
+AllocNonRecursiveMutex(void)
 {
     PNRMUTEX m = (PNRMUTEX)PyMem_RawMalloc(sizeof(NRMUTEX));
     if (!m)

x86_64-w64-mingw32.cmake

SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

[longnguyen2004]

First off, thanks for working on this! I simply don't have the time to work on something this large. Regarding GetTickCount64, it requires _WIN32_WINNT >= 0x0600.

[RussellHaley]

Hey, no problem. I assure you my intentions are as self-centered as FOSS can be. :-)

Yes, I noted the version of _WIN32_WINNT, thank you. I couldn't get the existing defines to effect (affect?) GetTickCount64 or ALL_PROCESSOR_GROUPS. I will keep working on that.

The _freeze_importlib C file includes Python.h and so it has the requirement for a python library. Ubuntu (apt) has a python3.8-dev package that could potentially be used to build _freeze_importlib for the host if we don't want to build libpython for linux first.

So I see a couple of ways forward:

1. Create a requirement in lldb-mi for wine so we can use the existing CMAKE emulator feature. [Someone else would have to do that; I won't touch it. (ha ha)]
2. Try to detect if the host is Linux/Freebsd/macOS and _win32 is defined. Alternatively...
3. Create a flag to override the current behaviour and build _freeze_importlib for a specific platform (or just build for host).

If we go with 2 or 3, then use cmake FIND to look for a native python for the correct (host) architecture. If a python 3 library (and header) doesn't exist, fail the FIND step and build python for the host.

I like the idea of item 3 and I think it would be the most acceptable to suggest to upstream maintainers? lldb, lldb-mi and python-cmake-buildsystem could all potentially benefit from this work.

I have some cmake source code that I can model from to create the steps described above.

Thoughts? I'll keep noodling on it.

[mstorsjo]

The _freeze_importlib C file includes Python.h and so it has the requirement for a python library. Ubuntu (apt) has a python3.8-dev package that could potentially be used to build _freeze_importlib for the host if we don't want to build libpython for linux first.

So I see a couple of ways forward:

1. Create a requirement in lldb-mi for wine so we can use the existing CMAKE emulator feature. [Someone else would have to do that; I won't touch it. (ha ha)]
2. Try to detect if the host is Linux/Freebsd/macOS and _win32 is defined. Alternatively...
3. Create a flag to override the current behaviour and build _freeze_importlib for a specific platform (or just build for host).

Regarding this, keep in mind that you generally can't assume that you can (easily) run the output binaries from the cross compiler with a tool like wine; it just so happens to work when cross compiling from x86 linux to x86 windows, but when cross compiling from x86 linux to arm windows, or from arm linux to x86 windows for that matter, one can't rely on such procedures.

I guess in your particular case, you're only interested in x86, but it's useful to keep in mind.

So for such cases, you need to build things for linux (or use the distribution's -dev packages). The open question, in those cases, is, how closely does the native linux python configuration need to match the newly built cross target? I.e. is it fine with a distro-provided linux python 3.5 while cross compiling python 3.7 for windows? Is there anything very version specific, or configuration specific, in the freeze_importlib tool, or is it just a plain tool that works the same however you manage to produce it?

[longnguyen2004]

@RussellHaley Do you have a branch set up? I can try to test it in WSL.

[RussellHaley]

@longnguyen2004, no the patches above are all that I have at the moment. I cloned the python-make-buildsystem, then ran a build for linux. The initial build pulls down the python source code (and uncompresses them) and auto-magically applies patches. I then made the above changes manually as I was going. I'll email the patches to you momentarily.

[RussellHaley]

The _freeze_importlib C file includes Python.h and so it has the requirement for a python library. Ubuntu (apt) has a python3.8-dev package that could potentially be used to build _freeze_importlib for the host if we don't want to build libpython for linux first. So I see a couple of ways forward:

1. Create a requirement in lldb-mi for wine so we can use the existing CMAKE emulator feature. [Someone else would have to do that; I won't touch it. (ha ha)]
2. Try to detect if the host is Linux/Freebsd/macOS and _win32 is defined. Alternatively...
3. Create a flag to override the current behaviour and build _freeze_importlib for a specific platform (or just build for host).

Regarding this, keep in mind that you generally can't assume that you can (easily) run the output binaries from the cross compiler with a tool like wine; it just so happens to work when cross compiling from x86 linux to x86 windows, but when cross compiling from x86 linux to arm windows, or from arm linux to x86 windows for that matter, one can't rely on such procedures.

I promise I will not be looking at wine. I'm a teetotaler. :+1:

I guess in your particular case, you're only interested in x86, but it's useful to keep in mind.

So for such cases, you need to build things for linux (or use the distribution's -dev packages). The open question, in those cases, is, how closely does the native linux python configuration need to match the newly built cross target? I.e. is it fine with a distro-provided linux python 3.5 while cross compiling python 3.7 for windows? Is there anything very version specific, or configuration specific, in the freeze_importlib tool, or is it just a plain tool that works the same however you manage to produce it?

Thank you, very insightful. The source code for _freeze_importlib is the same for both cases (no defines in the C either) and there doesn't seem to be any windows specific patches to the Python sources (I can build for linux and windows without modifying the build).

A question: There is a very complex #if block in the mingw configuration header. If they are using the Windows 7 API then I see no need to keep this block?

#if !defined(MS_WIN64) && defined(__MINGW64__)
#  define MS_WIN64
#endif

#ifdef MS_WIN64
#  define MS_WINX64
#endif

/* set the version macros for the windows headers */
#ifdef MS_WINX64
/* 64 bit only runs on XP or greater */
#  define Py_WINVER _WIN32_WINNT_WINXP
#  define Py_NTDDI NTDDI_WINXP
#else
/* Python 2.6+ requires Windows 2000 or greater */
#  ifdef _WIN32_WINNT_WIN2K
#    define Py_WINVER _WIN32_WINNT_WIN2K
#  else
#    define Py_WINVER 0x0500
#  endif
#  define Py_NTDDI NTDDI_WIN2KSP4
#endif

It could be replaced with this:

#define Py_WINVER _WIN32_WINNT_WIN7 //0x0601
#define Py_NTDDI NTDDI_WIN7 //0x0601

What are the chances of Pre-Windows 7 instances? I'd say pretty slim. Perhaps add a pre-processor error?

This block that follows it may also be redundant (but I won't touch it for now):

/* We only set these values when building Python - we don't want to force
   these values on extensions, as that will affect the prototypes and
   structures exposed in the Windows headers. Even when building Python, we
   allow a single source file to override this - they may need access to
   structures etc so it can optionally use new Windows features if it
   determines at runtime they are available.
*/
#if defined(Py_BUILD_CORE) || defined(Py_BUILD_CORE_MODULE)
#  ifndef NTDDI_VERSION
#    define NTDDI_VERSION Py_NTDDI
#  endif
#  ifndef WINVER
#    define WINVER Py_WINVER
#  endif
#  ifndef _WIN32_WINNT
#    define _WIN32_WINNT Py_WINVER
#  endif
#endif /* defined(Py_BUILD_CORE) || defined(Py_BUILD_CORE_MODULE) */

[mstorsjo]

A question: There is a very complex #if block in the mingw configuration header. If they are using the Windows 7 API then I see no need to keep this block?

#if !defined(MS_WIN64) && defined(__MINGW64__)
#  define MS_WIN64
#endif

#ifdef MS_WIN64
#  define MS_WINX64
#endif

/* set the version macros for the windows headers */
#ifdef MS_WINX64
/* 64 bit only runs on XP or greater */
#  define Py_WINVER _WIN32_WINNT_WINXP
#  define Py_NTDDI NTDDI_WINXP
#else
/* Python 2.6+ requires Windows 2000 or greater */
#  ifdef _WIN32_WINNT_WIN2K
#    define Py_WINVER _WIN32_WINNT_WIN2K
#  else
#    define Py_WINVER 0x0500
#  endif
#  define Py_NTDDI NTDDI_WIN2KSP4
#endif

It could be replaced with this:

#define Py_WINVER _WIN32_WINNT_WIN7 //0x0601
#define Py_NTDDI NTDDI_WIN7   //0x0601

What are the chances of Pre-Windows 7 instances? I'd say pretty slim. Perhaps add a pre-processor error?

The LLVM ecosystem has most dropped support for pre-Windows 7; LLVM itself can only run on Windows 7 or newer. It can generate code for older versions, but libc++ also requires Windows 7, and iirc LLD by default marks executables as requiring at least Vista. So just bumping everything up to Win7, in this configuration at least, should be just fine. (Dunno what the support status is in upstream Python though.)

[RussellHaley]

"The LLVM ecosystem has most dropped support for pre-Windows 7; "

That is everything I needed to know. (I'll be switching back to LLVM-mingw after I'm satisfied on GNU).

[RussellHaley]

There are some define blocks in Pyton-3.6.7/Modules/posixmodule.c that were using _MSC_VER. I have changed those to _WIN32. Do you see anything untoward in the #ifdef _WIN32 block?

/* Various compilers have only certain posix functions */
/* XXX Gosh I wish these were all moved into pyconfig.h */
#if defined(__WATCOMC__) && !defined(__QNX__)           /* Watcom compiler */
#define HAVE_OPENDIR    1
#define HAVE_SYSTEM     1
#include <process.h>
#else
#ifdef _WIN32         /* Microsoft compiler */
#define HAVE_GETPPID    1
#define HAVE_GETLOGIN   1
#define HAVE_SPAWNV     1
#define HAVE_EXECV      1
#define HAVE_WSPAWNV    1
#define HAVE_WEXECV     1
#define HAVE_PIPE       1
#define HAVE_SYSTEM     1
#define HAVE_CWAIT      1
#define HAVE_FSYNC      1
#define fsync _commit
#else
/* Unix functions that the configure script doesn't check for */
#define HAVE_EXECV      1
#define HAVE_FORK       1
#if defined(__USLC__) && defined(__SCO_VERSION__)       /* SCO UDK Compiler */
#define HAVE_FORK1      1
#endif
#define HAVE_GETEGID    1
#define HAVE_GETEUID    1
#define HAVE_GETGID     1
#define HAVE_GETPPID    1
#define HAVE_GETUID     1
#define HAVE_KILL       1
#define HAVE_OPENDIR    1
#define HAVE_PIPE       1
#define HAVE_SYSTEM     1
#define HAVE_WAIT       1
#define HAVE_TTYNAME    1
#endif  /* _MSC_VER */
#endif  /* ! __WATCOMC__ || __QNX__ */

[RussellHaley]

Sorry, I'm going to walk that last question back. I found a mingw patch in the python-cmake-buildsystem repository for Python 2.6 that does a similar thing. I blended that patch into my patches and it seems to work (note the new block that uses _MINGW32_):

/* Various compilers have only certain posix functions */
/* XXX Gosh I wish these were all moved into pyconfig.h */
#if defined(__WATCOMC__) && !defined(__QNX__)           /* Watcom compiler */
#define HAVE_OPENDIR    1
#define HAVE_SYSTEM     1
#include <process.h>
#else
#ifdef _MSC_VER         /* Microsoft compiler */
#define HAVE_GETPPID    1
#define HAVE_GETLOGIN   1
#define HAVE_SPAWNV     1
#define HAVE_EXECV      1
#define HAVE_WSPAWNV    1
#define HAVE_WEXECV     1
#define HAVE_PIPE       1
#define HAVE_SYSTEM     1
#define HAVE_CWAIT      1
#define HAVE_FSYNC      1
#define fsync _commit
#else
#if defined(__MINGW32__)
#define HAVE_EXECV      1
#if defined(__USLC__) && defined(__SCO_VERSION__)       /* SCO UDK Compiler */
#define HAVE_FORK1      1
#endif
#define HAVE_GETCWD     1
#define HAVE_OPENDIR    1
#define HAVE_PIPE       1
#ifndef __rtems__
#define HAVE_POPEN      1
#endif
#define HAVE_SYSTEM     1
#else /* all other compilers */
/* Unix functions that the configure script doesn't check for */
#define HAVE_EXECV      1
#define HAVE_FORK       1
#if defined(__USLC__) && defined(__SCO_VERSION__)       /* SCO UDK Compiler */
#define HAVE_FORK1      1
#endif
#define HAVE_GETEGID    1
#define HAVE_GETEUID    1
#define HAVE_GETGID     1
#define HAVE_GETPPID    1
#define HAVE_GETUID     1
#define HAVE_KILL       1
#define HAVE_OPENDIR    1
#define HAVE_PIPE       1
#define HAVE_SYSTEM     1
#define HAVE_WAIT       1
#define HAVE_TTYNAME    1
#endif  /* _MINGW32_ */
#endif  /* _MSC_VER */
#endif  /* ! __WATCOMC__ || __QNX__ */

[RussellHaley]

This was tested with a shiny new llvm-mingw build.

git clone https://github.com/WinLua/python-cmake-buildsystem.git
cd python-cmake-buildsystem/
git checkout py3.6.7-mingw-patch
mkdir build-ninja-windows; cd build-ninja-windows
cmake -G"Ninja" -DCMAKE_TOOLCHAIN_FILE="../cmake/x86_64-w64-mingw32.cmake" \
-DCOMPILERPATH="/home/osboxes/llvm-mingw-host/bin/"  ..
ninja

[The -DCOMPILERPATH is a temporary thing for me at the moment. I don't want to add llvm-mingw to my path currently, I'm sure there is a better cmake way to do this.]

I used their build tools to apply the mingw patch to the python sources. I put in a hack to get the importlib headers until I write the custom command to build _freeze_importlib for the host. At the moment, I just copy the importlib.h and importlib_external.h files from another directory in the repo.

I've been at this for two days and I still haven't tested if the executables work on windows. ¯\_(ツ)_/¯

[longnguyen2004]

I've been at this for two days and I still haven't tested if the executables work on windows. ¯\_(ツ)_/¯

Just use Wine I guess :)

[The -DCOMPILERPATH is a temporary thing for me at the moment. I don't want to add llvm-mingw to my path currently, I'm sure there is a better cmake way to do this.]

You can specify CMAKE_C_COMPILER and CMAKE_CXX_COMPILER, unless there are other things requiring the compiler path.

[RussellHaley]

I've been at this for two days and I still haven't tested if the executables work on windows. ¯\_(ツ)_/¯

Just use Wine I guess :)

Or I could stop "wining" and just transfer the files. I don't know why I am such a sour grape about Windows emulation.

[The -DCOMPILERPATH is a temporary thing for me at the moment. I don't want to add llvm-mingw to my path currently, I'm sure there is a better cmake way to do this.]

You can specify CMAKE_C_COMPILER and CMAKE_CXX_COMPILER, unless there are other things requiring the compiler path.

Those are specified in the toolchain file. I haven't tested my workflow yet, but if COMPILERPATH isn't specified it should just use the system cross compiler because the variable is blank. Looking at it now, the toolchain file will fail if it doesn't have a slash on the end of COMPILERPATH. Anyway, it's just a hack that should allow me to test against gnu and llvm for now.

[RussellHaley]

Here is a progress update. I am sorry I don't have any build output to share at the moment.

I had trouble getting cmake to recognize my cross built python, but this cmake command seems to configure the build correctly:

cmake \
    -G "Ninja" \
    -DCMAKE_TOOLCHAIN_FILE="~/x86_64-w64-mingw32.cmake" \
    -DCMAKE_INSTALL_PREFIX="deploy" \
    -DCMAKE_BUILD_TYPE=Release \
    -DLLVM_ENABLE_PROJECTS="clang;lld;lldb" \
    -DLLVM_TARGETS_TO_BUILD="ARM;AArch64;X86" \
    -DLLVM_INSTALL_TOOLCHAIN_ONLY=OFF \
    -DLLVM_HOST_TRIPLE=x86_64-w64-mingw32 \
    -DLLDB_ENABLE_LIBEDIT=OFF \
    -DPYTHON_HOME="/home/osboxes/python-cmake-install" \
    -DPYTHON_LIBRARIES="/home/osboxes/python-cmake-install/libs/libpython36.a" \
    -DPYTHON_INCLUDE_DIRS="/home/osboxes/python-cmake-install/include" \
    -DPYTHON_EXECUTABLE="/home/osboxes/python-cmake-install/bin/python.exe" \
    -DLLDB_PYTHON_RELATIVE_PATH="python-3.6.7" \
    -DLLDB_ENABLE_PYTHON=ON \
    -DLLDB_ENABLE_CURSES=OFF \
    -DLLDB_ENABLE_LUA=OFF \
    -DLLDB_INCLUDE_TESTS=OFF \
    ../llvm

The problem is LLDB_ENABLE_PYTHON seems to require llvm-config. Since it isn't part of the default llvm-mingw build, cmake tries to compile a NATIVE version of llvm-config, which fails. (I also crammed the python flags into the build-llvm.sh script and saw the same issue). I added llvm-config to the llvm-mingw LLVM_TOOLCHAIN_TOOLS flag and tried rebuilding my host toolchain, but the host compiler build fails because it can't find something called xray.

@mstorsjo, do you know what xray is and how I might build it? I'll try and get build output tonight. If nobody here has any suggestions I will fall back to the lldb-dev mailing list.

Thanks! Russ

[mstorsjo]

cmake \
    -G "Ninja" \
    -DCMAKE_TOOLCHAIN_FILE="~/x86_64-w64-mingw32.cmake" \
    -DCMAKE_INSTALL_PREFIX="deploy" \
    -DCMAKE_BUILD_TYPE=Release \
    -DLLVM_ENABLE_PROJECTS="clang;lld;lldb" \
    -DLLVM_TARGETS_TO_BUILD="ARM;AArch64;X86" \
    -DLLVM_INSTALL_TOOLCHAIN_ONLY=OFF \
    -DLLVM_HOST_TRIPLE=x86_64-w64-mingw32 \
    -DLLDB_ENABLE_LIBEDIT=OFF \
    -DPYTHON_HOME="/home/osboxes/python-cmake-install" \
    -DPYTHON_LIBRARIES="/home/osboxes/python-cmake-install/libs/libpython36.a" \
    -DPYTHON_INCLUDE_DIRS="/home/osboxes/python-cmake-install/include" \
    -DPYTHON_EXECUTABLE="/home/osboxes/python-cmake-install/bin/python.exe" \
    -DLLDB_PYTHON_RELATIVE_PATH="python-3.6.7" \
    -DLLDB_ENABLE_PYTHON=ON \
    -DLLDB_ENABLE_CURSES=OFF \
    -DLLDB_ENABLE_LUA=OFF \
    -DLLDB_INCLUDE_TESTS=OFF \
    ../llvm

The problem is LLDB_ENABLE_PYTHON seems to require llvm-config. Since it isn't part of the default llvm-mingw build, cmake tries to compile a NATIVE version of llvm-config, which fails. (I also crammed the python flags into the build-llvm.sh script and saw the same issue). I added llvm-config to the llvm-mingw LLVM_TOOLCHAIN_TOOLS flag and tried rebuilding my host toolchain, but the host compiler build fails because it can't find something called xray.

@mstorsjo, do you know what xray is and how I might build it? I'll try and get build output tonight. If nobody here has any suggestions I will fall back to the lldb-dev mailing list.

When cross-building llvm and similar things, it does indeed need a native version of llvm-config, llvm-tblgen and a few other *-tblgen. You can either point it at such an existing tool (if available), or it'll try to build it automatically.

Unfortunately, the automatic building of native tools when cross building has got an odd detail, where it automatically passes CMAKE_CXX_COMPILER and a few other vars from the outer cross build to the inner native build. (See https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/CrossCompile.cmake#L19-L25 for details.)

You can sidestep this by setting -DCROSS_TOOLCHAIN_FLAGS_NATIVE= in the build; if unset, this variable is set to copy a few vars to the inner build, but if set (but empty, or containing other flags) it'll skip any automatic propagation. See https://github.com/mstorsjo/llvm-mingw/blob/master/build-llvm.sh#L108-L120 for what I set when cross building llvm. (The extra LLDB disable options in CROSS_TOOLCHAIN_FLAGS_NATIVE might not be necessary any longer, they were earlier though. So at this point, just setting it to an empty string might have the same effect.)

So if this bit is solved, I believe the xray bit of the isn't something to follow up on at this stage?

[RussellHaley]

Thank you, martin. Yes, let me sort myself out and see if xray is still an issue.

[RussellHaley]

Ah, okay. So it appears you were indicating there is more to the storey of llvm-config and xray. I thought I would pro-actively build llvm-config and the various *-tblgen tools. I figured out the hard way that compiler-rt doesn't like to build if llvm-config is present. Noted.

I fell back to your script and patched it with a flag:

osboxes@osboxes ~/g/llvm-mingw (master)> git st
## master...origin/master
 M build-cross-tools.sh
 M build-llvm.sh
osboxes@osboxes ~/g/llvm-mingw (master)> git diff
diff --git a/build-cross-tools.sh b/build-cross-tools.sh
index c73fe87..06bd57e 100755
--- a/build-cross-tools.sh
+++ b/build-cross-tools.sh
@@ -27,7 +27,7 @@ CROSS_ARCH="$3"
 export PATH="$NATIVE/bin:$PATH"
 HOST=$CROSS_ARCH-w64-mingw32

-./build-llvm.sh $PREFIX --host=$HOST
+./build-llvm.sh $PREFIX --host=$HOST --lldb-py
 ./strip-llvm.sh $PREFIX --host=$HOST
 ./build-mingw-w64-tools.sh $PREFIX --skip-include-triplet-prefix --host=$HOST
 ./install-wrappers.sh $PREFIX --host=$HOST
diff --git a/build-llvm.sh b/build-llvm.sh
index b0bcb0e..3864c3c 100755
--- a/build-llvm.sh
+++ b/build-llvm.sh
@@ -37,6 +37,9 @@ while [ $# -gt 0 ]; do
     --host=*)
         HOST="${1#*=}"
         ;;
+    --lldb-py)
+        LLDB_PY=1
+        ;;
     *)
         PREFIX="$1"
         ;;
@@ -105,7 +108,22 @@ if [ -n "$HOST" ]; then
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_C_COMPILER=$HOST-gcc"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_CXX_COMPILER=$HOST-g++"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_RC_COMPILER=$HOST-windres"
-    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_PYTHON=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"
+    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"
+
+    if [ -n "$LLDB_PY" ]; then
+
+        PYTHON_VER="3.6.7"
+        PYTHON_PATH="/home/osboxes/python-cmake-install"
+
+        CMAKEFLAGS="$CMAKEFLAGS -DLLDB_ENABLE_PYTHON=ON"
+        CMAKEFLAGS="$CMAKEFLAGS -DPYTHON_HOME=$PYTHON_PATH"
+        CMAKEFLAGS="$CMAKEFLAGS -DPYTHON_LIBRARIES=$PYTHON_PATH/libs/libpython36.a"
+        CMAKEFLAGS="$CMAKEFLAGS -DPYTHON_INCLUDE_DIRS=$PYTHON_PATH/include/python36"
+        CMAKEFLAGS="$CMAKEFLAGS -DPYTHON_EXECUTABLE=$PYTHON_PATH/bin/python.exe"
+        CMAKEFLAGS="$CMAKEFLAGS -DLLDB_PYTHON_RELATIVE_PATH=python-$PYTHON_VER;"
+    else
+        CMAKEFLAGS="$CMAKEFLAGS -DLLDB_ENABLE_PYTHON=OFF"
+    fi

     native=$(find_native_tools)
     if [ -n "$native" ]; then

This came painfully close to succeeding but ended on this error:

osboxes@osboxes ~/g/llvm-mingw (master) [2]> ./build-cross-tools.sh ~/llvm-mingw-host/ ~/llvm-mingw-x86_64 x86_64
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR) 
-- Native target architecture is X86
-- Threads enabled.
-- Doxygen disabled.
-- Go bindings disabled.
-- Ninja version: 1.10.0
-- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH) 
-- OCaml bindings disabled.
-- LLVM host triple: x86_64-w64-mingw32
-- LLVM default target triple: x86_64-w64-mingw32
-- Constructing LLVMBuild project information
-- Setting native build dir to /home/osboxes/git/llvm-mingw/llvm-project/llvm/build-x86_64-w64-mingw32/NATIVE
-- LLVMHello ignored -- Loadable modules not supported on this platform.
-- Targeting ARM
-- Targeting AArch64
-- Targeting X86
-- Clang version: 11.0.0
-- PrintFunctionNames ignored -- Loadable modules not supported on this platform.
-- AnnotateFunctions ignored -- Loadable modules not supported on this platform.
-- Attribute ignored -- Loadable modules not supported on this platform.
-- LLD version: 11.0.0
-- Enable editline support in LLDB: FALSE
-- Enable curses support in LLDB: FALSE
-- Could NOT find LibLZMA (missing: LIBLZMA_LIBRARY LIBLZMA_INCLUDE_DIR LIBLZMA_HAS_AUTO_DECODER LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) 
-- Enable LZMA compression support in LLDB: FALSE
-- Enable Lua scripting support in LLDB: FALSE
-- Enable Python scripting support in LLDB: TRUE
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR) (Required is at least version "2.8")
-- Enable Libxml 2 support in LLDB: FALSE
-- LLDB version: 11.0.0
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR) 
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
-- Could NOT find epydoc
-- BugpointPasses ignored -- Loadable modules not supported on this platform.
-- Version: 0.0.0
-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES -- failed to compile
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- failed to compile
CMake Warning at utils/benchmark/CMakeLists.txt:244 (message):
  Using std::regex with exceptions disabled is not fully supported

-- Performing Test HAVE_STEADY_CLOCK -- compiled but failed to run
-- Configuring done
-- Generating done
-- Build files have been written to: /home/osboxes/git/llvm-mingw/llvm-project/llvm/build-x86_64-w64-mingw32
[848/1219] Building CXX object tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj
FAILED: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj 
/home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-g++ -DEXPORT_LIBLLDB -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLLDB_CONFIGURATION_RELEASE -DUNICODE -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_FILE_OFFSET_BITS=64 -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/API -I../tools/lldb/source/API -Itools/lldb/source -I../tools/lldb/include -Itools/lldb/include -Iinclude -I../include -I/home/osboxes/python-cmake-install/include/python36 -I../tools/clang/include -Itools/lldb/../clang/include -I../tools/lldb/source/. -Wa,-mbig-obj -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wstring-conversion -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG  -fno-exceptions -fno-rtti -std=c++14  -w -Wno-sequence-point -Wno-cast-qual -MD -MT tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj -MF tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj.d -o tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj -c tools/lldb/bindings/LLDBWrapPython.cpp
In file included from tools/lldb/bindings/LLDBWrapPython.cpp:3188:
In file included from ../tools/lldb/include/../source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h:58:
In file included from ../tools/lldb/include/lldb/Host/File.h:13:
In file included from ../tools/lldb/include/lldb/Utility/IOObject.h:16:
In file included from ../tools/lldb/include/lldb/lldb-private.h:15:
In file included from ../tools/lldb/include/lldb/lldb-private-enumerations.h:13:
In file included from ../include/llvm/Support/FormatProviders.h:20:
In file included from ../include/llvm/ADT/Twine.h:12:
In file included from ../include/llvm/ADT/SmallVector.h:20:
In file included from ../include/llvm/Support/MathExtras.h:20:
/home/osboxes/llvm-mingw-host/x86_64-w64-mingw32/include/c++/v1/cmath:406:9: error: no member named '_copysign' in the global namespace
using ::copysign;
      ~~^
/home/osboxes/python-cmake-install/include/python36/pyconfig.h:107:18: note: expanded from macro 'copysign'
#define copysign _copysign
                 ^
1 error generated.
[854/1219] Building CXX object tools/lldb/tools/lldb-instr/CMakeFiles/lldb-instr.dir/Instrument.cpp.obj
ninja: build stopped: subcommand failed.

[RussellHaley]

Incidentally, this work has brought lldb and the associated tools to my attention. Is it necessary to build lldb for a Linux host system? lldb-instr and lldb-server are quite large. I wonder if we could save some significant cycles not building it for the host?

osboxes@osboxes ~/g/llvm-mingw (master)> ll ~/llvm-mingw-host/bin/lldb*
-rwxr-xr-x 1 osboxes osboxes 275K Jan 16 23:00 /home/osboxes/llvm-mingw-host/bin/lldb*
-rwxr-xr-x 1 osboxes osboxes 163K Jan 16 23:00 /home/osboxes/llvm-mingw-host/bin/lldb-argdumper*
-rwxr-xr-x 1 osboxes osboxes  52M Jan 16 23:00 /home/osboxes/llvm-mingw-host/bin/lldb-instr*
-rwxr-xr-x 1 osboxes osboxes  20M Jan 16 23:00 /home/osboxes/llvm-mingw-host/bin/lldb-server*
-rwxr-xr-x 1 osboxes osboxes 395K Jan 16 23:00 /home/osboxes/llvm-mingw-host/bin/lldb-vscode*

[longnguyen2004]

Try compiling a newer version of Python? The copysign macro is removed from Python 3.8 onward (https://bugs.python.org/issue42120)

[longnguyen2004]

I thought I would pro-actively build llvm-config and the various *-tblgen tools.

Or just install LLVM from your package manager to get the native llvm-config and llvm-tblgen. At least that's the approach I used for building the toolchain on WSL.

[mstorsjo]

Ah, okay. So it appears you were indicating there is more to the storey of llvm-config and xray. I thought I would pro-actively build llvm-config and the various *-tblgen tools. I figured out the hard way that compiler-rt doesn't like to build if llvm-config is present. Noted.

That sounds surprising. Can you elaborate on it? The runtimes (compiler-rt, libunwind, libcxxabi, libcxx) do behave a bit differently if they find llvm-config wrt if it isn't found, but I should have continuous testing of that case. If you pass --full-llvm when you build the initial unix hosted llvm, you'll get llvm-config, llvm-tblgen and all other potentially useful debugging tools installed.

I fell back to your script and patched it with a flag:

osboxes@osboxes ~/g/llvm-mingw (master)> git st
## master...origin/master
 M build-cross-tools.sh
 M build-llvm.sh
osboxes@osboxes ~/g/llvm-mingw (master)> git diff
diff --git a/build-cross-tools.sh b/build-cross-tools.sh
index c73fe87..06bd57e 100755
--- a/build-cross-tools.sh
+++ b/build-cross-tools.sh
@@ -27,7 +27,7 @@ CROSS_ARCH="$3"
 export PATH="$NATIVE/bin:$PATH"
 HOST=$CROSS_ARCH-w64-mingw32

-./build-llvm.sh $PREFIX --host=$HOST
+./build-llvm.sh $PREFIX --host=$HOST --lldb-py
 ./strip-llvm.sh $PREFIX --host=$HOST
 ./build-mingw-w64-tools.sh $PREFIX --skip-include-triplet-prefix --host=$HOST
 ./install-wrappers.sh $PREFIX --host=$HOST
diff --git a/build-llvm.sh b/build-llvm.sh
index b0bcb0e..3864c3c 100755
--- a/build-llvm.sh
+++ b/build-llvm.sh
@@ -37,6 +37,9 @@ while [ $# -gt 0 ]; do
     --host=*)
         HOST="${1#*=}"
         ;;
+    --lldb-py)
+        LLDB_PY=1
+        ;;
     *)
         PREFIX="$1"
         ;;
@@ -105,7 +108,22 @@ if [ -n "$HOST" ]; then
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_C_COMPILER=$HOST-gcc"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_CXX_COMPILER=$HOST-g++"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_RC_COMPILER=$HOST-windres"
-    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_PYTHON=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"
+    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"

FWIW, you don't need to touch this line. It's only used for configuring the native build, which only builds lldb-tblgen, but not actually build anything.

This came painfully close to succeeding but ended on this error:

In file included from ../include/llvm/Support/MathExtras.h:20:
/home/osboxes/llvm-mingw-host/x86_64-w64-mingw32/include/c++/v1/cmath:406:9: error: no member named '_copysign' in the global namespace
using ::copysign;
      ~~^
/home/osboxes/python-cmake-install/include/python36/pyconfig.h:107:18: note: expanded from macro 'copysign'
#define copysign _copysign
                 ^
1 error generated.
[854/1219] Building CXX object tools/lldb/tools/lldb-instr/CMakeFiles/lldb-instr.dir/Instrument.cpp.obj
ninja: build stopped: subcommand failed.

That's odd - if _copysign is missing, it should IMO trigger this error every time cmath is included. So apparently something in the environment before including things here, has changed something, affecting the copysign symbols... Using a newer version of python that doesn't touch/use copysign might help though.

Incidentally, this work has brought lldb and the associated tools to my attention. Is it necessary to build lldb for a Linux host system? lldb-instr and lldb-server are quite large. I wonder if we could save some significant cycles not building it for the host?

You could save some cycles and disk space that way, but not a huge deal - it's rather quick to build compared to the rest. (IIRC around only 1/6th of the build time is for LLDB.) And while normally you wouldn't use lldb in the cross compile environment, it can be used there as well (with remote debugging with lldb-server, or for doing debugger style inspection of a binary and a crashdump).

I thought I would pro-actively build llvm-config and the various *-tblgen tools.

Or just install LLVM from your package manager to get the native llvm-config and llvm-tblgen. At least that's the approach I used for building the toolchain on WSL.

In that case, you might need to be kinda careful to get the exact right version of llvm-tblgen as I think there can be differences between versions with how it handles the tablegen sources in llvm. AFAIK it's not a public interface intended to be stable across releases.

In practice, cross building llvm works probably the easiest as long as you just set -DCROSS_TOOLCHAIN_FLAGS_NATIVE=, then those tools are built transparently (and the extra effort in building llvm-config/llvm-tblgen twice is pretty minimal). But my build-llvm.sh script tries to pick up an already built version of them from the build dir, if they happen to exist in place still.

[longnguyen2004]

Python 3.9.1 is a nightmare to build with the CMake build system, because many files are added, others are deleted, and patches no longer work. I'm wondering why they don't support mingw in the first place.

[RussellHaley]

Python 3.9.1 is a nightmare to build with the CMake build system, because many files are added, others are deleted, and patches no longer work. I'm wondering why they don't support mingw in the first place.

Yes, I was quite frustrated as well. It seems to me that the project has diminished and was only barely supporting 3.6.7. Now, with that said, we are not likely interested in all of python. It seems to me that lldb only needs libpython36.a. If we can get away with just building the static library then we may be able to jettison or ignore large parts of the python build? I'm happy to push some patches upstream to them if it makes sense, but I am only doing this for KDevelop debugger support. If we wind up with a custom cmake script, so be it.

My thinking was to get as much of python working as I can to get something to build. I briefly tested the python36 executable on Windows and it "ran" but errored out due to some missing python libraries. Python couldn't find a 'filesystem codec' or some such thing; which might be due to my wonky _freeze_importlib process. BUT, since python.exe ran correctly on Windows, I assume for the moment that libpython36.a is valid (I also did examine to ensure the objects in the archive were COFF).

[RussellHaley]

Ah, okay. So it appears you were indicating there is more to the storey of llvm-config and xray. I thought I would pro-actively build llvm-config and the various *-tblgen tools. I figured out the hard way that compiler-rt doesn't like to build if llvm-config is present. Noted.

That sounds surprising. Can you elaborate on it? The runtimes (compiler-rt, libunwind, libcxxabi, libcxx) do behave a bit differently if they find llvm-config wrt if it isn't found, but I should have continuous testing of that case. If you pass --full-llvm when you build the initial unix hosted llvm, you'll get llvm-config, llvm-tblgen and all other potentially useful debugging tools installed.

Okay, I'll get back to you on this.

I fell back to your script and patched it with a flag:

osboxes@osboxes ~/g/llvm-mingw (master)> git st
## master...origin/master
 M build-cross-tools.sh
 M build-llvm.sh
osboxes@osboxes ~/g/llvm-mingw (master)> git diff
diff --git a/build-cross-tools.sh b/build-cross-tools.sh
index c73fe87..06bd57e 100755
--- a/build-cross-tools.sh
+++ b/build-cross-tools.sh
@@ -27,7 +27,7 @@ CROSS_ARCH="$3"
 export PATH="$NATIVE/bin:$PATH"
 HOST=$CROSS_ARCH-w64-mingw32

-./build-llvm.sh $PREFIX --host=$HOST
+./build-llvm.sh $PREFIX --host=$HOST --lldb-py
 ./strip-llvm.sh $PREFIX --host=$HOST
 ./build-mingw-w64-tools.sh $PREFIX --skip-include-triplet-prefix --host=$HOST
 ./install-wrappers.sh $PREFIX --host=$HOST
diff --git a/build-llvm.sh b/build-llvm.sh
index b0bcb0e..3864c3c 100755
--- a/build-llvm.sh
+++ b/build-llvm.sh
@@ -37,6 +37,9 @@ while [ $# -gt 0 ]; do
     --host=*)
         HOST="${1#*=}"
         ;;
+    --lldb-py)
+        LLDB_PY=1
+        ;;
     *)
         PREFIX="$1"
         ;;
@@ -105,7 +108,22 @@ if [ -n "$HOST" ]; then
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_C_COMPILER=$HOST-gcc"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_CXX_COMPILER=$HOST-g++"
     CMAKEFLAGS="$CMAKEFLAGS -DCMAKE_RC_COMPILER=$HOST-windres"
-    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_PYTHON=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"
+    CMAKEFLAGS="$CMAKEFLAGS -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DLLDB_ENABLE_LIBEDIT=OFF;-DLLDB_ENABLE_CURSES=OFF;-DLLDB_ENABLE_LUA=OFF"

FWIW, you don't need to touch this line. It's only used for configuring the native build, which only builds lldb-tblgen, but not actually build anything.

This came painfully close to succeeding but ended on this error:

In file included from ../include/llvm/Support/MathExtras.h:20:
/home/osboxes/llvm-mingw-host/x86_64-w64-mingw32/include/c++/v1/cmath:406:9: error: no member named '_copysign' in the global namespace
using ::copysign;
      ~~^
/home/osboxes/python-cmake-install/include/python36/pyconfig.h:107:18: note: expanded from macro 'copysign'
#define copysign _copysign
                 ^
1 error generated.
[854/1219] Building CXX object tools/lldb/tools/lldb-instr/CMakeFiles/lldb-instr.dir/Instrument.cpp.obj
ninja: build stopped: subcommand failed.

That's odd - if _copysign is missing, it should IMO trigger this error every time cmath is included. So apparently something in the environment before including things here, has changed something, affecting the copysign symbols... Using a newer version of python that doesn't touch/use copysign might help though.

Thanks, I'll drill in a little more on 3.6 given the issues @longnguyen2004 is having.

Incidentally, this work has brought lldb and the associated tools to my attention. Is it necessary to build lldb for a Linux host system? lldb-instr and lldb-server are quite large. I wonder if we could save some significant cycles not building it for the host?

You could save some cycles and disk space that way, but not a huge deal - it's rather quick to build compared to the rest. (IIRC around only 1/6th of the build time is for LLDB.) And while normally you wouldn't use lldb in the cross compile environment, it can be used there as well (with remote debugging with lldb-server, or for doing debugger style inspection of a binary and a crashdump).

I thought I would pro-actively build llvm-config and the various *-tblgen tools.

Or just install LLVM from your package manager to get the native llvm-config and llvm-tblgen. At least that's the approach I used for building the toolchain on WSL.

In that case, you might need to be kinda careful to get the exact right version of llvm-tblgen as I think there can be differences between versions with how it handles the tablegen sources in llvm. AFAIK it's not a public interface intended to be stable across releases.

In practice, cross building llvm works probably the easiest as long as you just set -DCROSS_TOOLCHAIN_FLAGS_NATIVE=, then those tools are built transparently (and the extra effort in building llvm-config/llvm-tblgen twice is pretty minimal).

Thank you for all your time explaining these things for me. I'll test --full-llvm when investigating the xray issue, but I'll stick to rebuilding those tools with -DCROSS_TOOLCHAIN_FLAGS_NATIVE= for this python task.

[longnguyen2004]

Should we take a look at all the MSYS2 patches for Python? There are quite a lot of patches, and they just updated to 3.8.7 as well.

[RussellHaley]

Should we take a look at all the MSYS2 patches for Python? There are quite a lot of patches, and they just updated to 3.8.7 as well.

Great idea!

[longnguyen2004]

And it might allow us to build Python using the usual autotools build system as well. Patches can be downloaded on the fly with a sparse checkout of the Mingw-w64 packages repo. However, going with this approach requires using autoreconf to regenerate the configure script, which requires Perl. But if @mstorsjo is ok with it then we should continue with that approach, since the CMake build system has suffered from severe rotting.

[RussellHaley]

This came painfully close to succeeding but ended on this error:

In file included from ../include/llvm/Support/MathExtras.h:20:
/home/osboxes/llvm-mingw-host/x86_64-w64-mingw32/include/c++/v1/cmath:406:9: error: no member named '_copysign' in the global namespace
using ::copysign;
      ~~^
/home/osboxes/python-cmake-install/include/python36/pyconfig.h:107:18: note: expanded from macro 'copysign'
#define copysign _copysign
                 ^
1 error generated.
[854/1219] Building CXX object tools/lldb/tools/lldb-instr/CMakeFiles/lldb-instr.dir/Instrument.cpp.obj
ninja: build stopped: subcommand failed.

That's odd - if _copysign is missing, it should IMO trigger this error every time cmath is included. So apparently something in the environment before including things here, has changed something, affecting the copysign symbols... Using a newer version of python that doesn't touch/use copysign might help though.

Thanks, I'll drill in a little more on 3.6 given the issues @longnguyen2004 is having.

The copy of pyconfig.h containing that define is the "patched" version (existing patch, not mine). I removed #defined codesign _codesign and rebuilt python without any issue. The lldb build now fails trying to link to the python library.

osboxes@osboxes ~/g/llvm-mingw (master)> ./build-cross-tools.sh ~/llvm-mingw-host/ ~/llvm-mingw-x86_64 x86_64
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR) 
-- Native target architecture is X86
-- Threads enabled.
-- Doxygen disabled.
-- Go bindings disabled.
-- Ninja version: 1.10.0
-- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH) 
-- OCaml bindings disabled.
-- LLVM host triple: x86_64-w64-mingw32
-- LLVM default target triple: x86_64-w64-mingw32
-- Constructing LLVMBuild project information
-- Setting native build dir to /home/osboxes/git/llvm-mingw/llvm-project/llvm/build-x86_64-w64-mingw32/NATIVE
-- LLVMHello ignored -- Loadable modules not supported on this platform.
-- Targeting ARM
-- Targeting AArch64
-- Targeting X86
-- Clang version: 11.0.0
-- PrintFunctionNames ignored -- Loadable modules not supported on this platform.
-- AnnotateFunctions ignored -- Loadable modules not supported on this platform.
-- Attribute ignored -- Loadable modules not supported on this platform.
-- LLD version: 11.0.0
-- Enable editline support in LLDB: FALSE
-- Enable curses support in LLDB: FALSE
-- Could NOT find LibLZMA (missing: LIBLZMA_LIBRARY LIBLZMA_INCLUDE_DIR LIBLZMA_HAS_AUTO_DECODER LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) 
-- Enable LZMA compression support in LLDB: FALSE
-- Enable Lua scripting support in LLDB: FALSE
-- Enable Python scripting support in LLDB: TRUE
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR) (Required is at least version "2.8")
-- Enable Libxml 2 support in LLDB: FALSE
-- LLDB version: 11.0.0
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR) 
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
-- Could NOT find epydoc
-- BugpointPasses ignored -- Loadable modules not supported on this platform.
-- Version: 0.0.0
-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES -- failed to compile
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- failed to compile
CMake Warning at utils/benchmark/CMakeLists.txt:244 (message):
  Using std::regex with exceptions disabled is not fully supported

-- Performing Test HAVE_STEADY_CLOCK -- compiled but failed to run
-- Configuring done
-- Generating done
-- Build files have been written to: /home/osboxes/git/llvm-mingw/llvm-project/llvm/build-x86_64-w64-mingw32
[57/294] Linking CXX shared library bin/liblldb.dll
FAILED: bin/liblldb.dll lib/libliblldb.dll.a 
: && /home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-g++ -Wa,-mbig-obj -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wstring-conversion -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG   -shared -o bin/liblldb.dll -Wl,--out-implib,lib/libliblldb.dll.a -Wl,--major-image-version,11,--minor-image-version,0 tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAddress.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAttachInfo.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBlock.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpoint.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpointLocation.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpointName.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpointOptionCommon.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBroadcaster.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBCommandInterpreter.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBCommandInterpreterRunOptions.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBCommandReturnObject.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBCommunication.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBCompileUnit.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBData.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBDebugger.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBDeclaration.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBEnvironment.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBError.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBEvent.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBExecutionContext.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBExpressionOptions.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBFileSpec.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBFile.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBFileSpecList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBFrame.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBFunction.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBHostOS.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBInstruction.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBInstructionList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBLanguageRuntime.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBLaunchInfo.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBLineEntry.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBListener.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBMemoryRegionInfo.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBMemoryRegionInfoList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBModule.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBModuleSpec.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBPlatform.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBProcess.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBProcessInfo.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBQueue.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBQueueItem.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBReproducer.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBSection.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBSourceManager.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBStream.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBStringList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBStructuredData.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBSymbol.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBSymbolContext.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBSymbolContextList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBThread.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBThreadCollection.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBThreadPlan.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTrace.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTraceOptions.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBType.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeCategory.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeEnumMember.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeFilter.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeFormat.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeNameSpecifier.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeSummary.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTypeSynthetic.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBValue.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBValueList.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBVariablesOptions.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBWatchpoint.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SBUnixSignals.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/SystemInitializerFull.cpp.obj tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj  lib/liblldbBase.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbHost.a  lib/liblldbInitialization.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbUtility.a  lib/liblldbPluginABIAArch64.a  lib/liblldbPluginABIARM.a  lib/liblldbPluginABIX86.a  lib/liblldbPluginArchitectureArm.a  lib/liblldbPluginArchitectureMips.a  lib/liblldbPluginArchitecturePPC64.a  lib/liblldbPluginDisassemblerLLVMC.a  lib/liblldbPluginDynamicLoaderDarwinKernel.a  lib/liblldbPluginDynamicLoaderMacOSXDYLD.a  lib/liblldbPluginDynamicLoaderPosixDYLD.a  lib/liblldbPluginDynamicLoaderStatic.a  lib/liblldbPluginDynamicLoaderHexagonDYLD.a  lib/liblldbPluginDynamicLoaderWindowsDYLD.a  lib/liblldbPluginDynamicLoaderWasmDYLD.a  lib/liblldbPluginInstructionARM.a  lib/liblldbPluginInstructionARM64.a  lib/liblldbPluginInstructionMIPS.a  lib/liblldbPluginInstructionMIPS64.a  lib/liblldbPluginInstructionPPC64.a  lib/liblldbPluginInstrumentationRuntimeASan.a  lib/liblldbPluginInstrumentationRuntimeMainThreadChecker.a  lib/liblldbPluginInstrumentationRuntimeTSan.a  lib/liblldbPluginInstrumentationRuntimeUBSan.a  lib/liblldbPluginJITLoaderGDB.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginObjCPlusPlusLanguage.a  lib/liblldbPluginCXXItaniumABI.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginMemoryHistoryASan.a  lib/liblldbPluginObjectContainerBSDArchive.a  lib/liblldbPluginObjectContainerMachOArchive.a  lib/liblldbPluginObjectFileBreakpad.a  lib/liblldbPluginObjectFileELF.a  lib/liblldbPluginObjectFileMachO.a  lib/liblldbPluginObjectFilePECOFF.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginObjectFileWasm.a  lib/liblldbPluginOperatingSystemPython.a  lib/liblldbPluginPlatformLinux.a  lib/liblldbPluginPlatformFreeBSD.a  lib/liblldbPluginPlatformNetBSD.a  lib/liblldbPluginPlatformOpenBSD.a  lib/liblldbPluginPlatformMacOSX.a  lib/liblldbPluginPlatformWindows.a  lib/liblldbPluginPlatformGDB.a  lib/liblldbPluginPlatformAndroid.a  lib/liblldbPluginProcessWindowsCommon.a  lib/liblldbPluginProcessGDBRemote.a  lib/liblldbPluginProcessElfCore.a  lib/liblldbPluginProcessMachCore.a  lib/liblldbPluginProcessMinidump.a  lib/liblldbPluginScriptInterpreterNone.a  lib/liblldbPluginScriptInterpreterPython.a  lib/liblldbPluginStructuredDataDarwinLog.a  lib/liblldbPluginSymbolFileBreakpad.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFileSymtab.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginSystemRuntimeMacOSX.a  lib/liblldbPluginSymbolVendorELF.a  lib/liblldbPluginSymbolVendorWasm.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbPluginUnwindAssemblyInstEmulation.a  lib/liblldbPluginUnwindAssemblyX86.a  lib/libLLVMSupport.a  lib/liblldbPluginDynamicLoaderWindowsDYLD.a  lib/libLLVMARMCodeGen.a  lib/libLLVMARMAsmParser.a  lib/libLLVMARMDisassembler.a  lib/libLLVMARMDesc.a  lib/libLLVMARMInfo.a  lib/libLLVMARMUtils.a  lib/libLLVMAArch64CodeGen.a  lib/libLLVMAArch64AsmParser.a  lib/libLLVMAArch64Disassembler.a  lib/libLLVMAArch64Desc.a  lib/libLLVMAArch64Info.a  lib/libLLVMAArch64Utils.a  lib/libLLVMX86CodeGen.a  lib/libLLVMAsmPrinter.a  lib/libLLVMCFGuard.a  lib/libLLVMGlobalISel.a  lib/libLLVMSelectionDAG.a  lib/libLLVMX86AsmParser.a  lib/libLLVMX86Desc.a  lib/libLLVMX86Disassembler.a  lib/libLLVMX86Info.a  -ldbghelp  lib/liblldbPluginPlatformLinux.a  lib/liblldbPluginPlatformGDB.a  lib/liblldbPluginDynamicLoaderDarwinKernel.a  lib/liblldbPluginPlatformMacOSX.a  lib/liblldbPluginPlatformPOSIX.a  lib/liblldbPluginDynamicLoaderMacOSXDYLD.a  lib/liblldbPluginObjectFileMachO.a  lib/liblldbPluginDynamicLoaderPosixDYLD.a  lib/liblldbPluginProcessElfCore.a  lib/liblldbPluginDynamicLoaderPosixDYLD.a  lib/liblldbPluginProcessElfCore.a  /home/osboxes/python-cmake-install/libs/libpython36.a  lib/liblldbPluginObjectFileBreakpad.a  lib/liblldbPluginObjectFileELF.a  lib/liblldbPluginObjectFileWasm.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbCommands.a  lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginProcessUtility.a  lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjCRuntime.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbCommands.a  lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginProcessUtility.a  lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjCRuntime.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbCommands.a  lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginProcessUtility.a  lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjCRuntime.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbCommands.a  lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginProcessUtility.a  lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjCRuntime.a  lib/liblldbBreakpoint.a  lib/liblldbCore.a  lib/liblldbDataFormatters.a  lib/liblldbExpression.a  lib/liblldbInterpreter.a  lib/liblldbSymbol.a  lib/liblldbTarget.a  lib/liblldbPluginCPlusPlusLanguage.a  lib/liblldbPluginObjCLanguage.a  lib/liblldbPluginAppleObjCRuntime.a  lib/liblldbPluginRenderScriptRuntime.a  lib/liblldbPluginObjectFileJIT.a  lib/liblldbPluginSymbolFileDWARF.a  lib/liblldbPluginSymbolFilePDB.a  lib/liblldbPluginTypeSystemClang.a  lib/liblldbCommands.a  lib/liblldbPluginExpressionParserClang.a  lib/liblldbPluginProcessUtility.a  lib/liblldbPluginClangCommon.a  lib/liblldbPluginCPPRuntime.a  lib/liblldbPluginSymbolFileNativePDB.a  lib/liblldbPluginObjCRuntime.a  lib/libLLVMDebugInfoDWARF.a  lib/liblldbBase.a  lib/libLLVMMCJIT.a  lib/libLLVMExecutionEngine.a  lib/libLLVMRuntimeDyld.a  lib/libclangCodeGen.a  lib/libLLVMCoverage.a  lib/libLLVMLTO.a  lib/libLLVMCodeGen.a  lib/libLLVMExtensions.a  lib/libLLVMObjCARCOpts.a  lib/libLLVMPasses.a  lib/libLLVMTarget.a  lib/libLLVMCoroutines.a  lib/libLLVMipo.a  lib/libLLVMIRReader.a  lib/libLLVMAsmParser.a  lib/libLLVMBitWriter.a  lib/libLLVMInstrumentation.a  lib/libLLVMLinker.a  lib/libLLVMVectorize.a  lib/libLLVMScalarOpts.a  lib/libLLVMAggressiveInstCombine.a  lib/libLLVMInstCombine.a  lib/libclangRewriteFrontend.a  lib/libclangFrontend.a  lib/libclangDriver.a  -lversion  lib/libLLVMOption.a  lib/libclangParse.a  lib/libclangRewrite.a  lib/libclangSerialization.a  lib/libclangSema.a  lib/libclangEdit.a  lib/libclangAnalysis.a  lib/libclangASTMatchers.a  lib/liblldbHost.a  lib/libclangAST.a  lib/libLLVMFrontendOpenMP.a  lib/libLLVMTransformUtils.a  lib/libLLVMAnalysis.a  lib/libLLVMProfileData.a  lib/libLLVMDebugInfoPDB.a  lib/libLLVMObject.a  lib/libLLVMBitReader.a  lib/libLLVMMCParser.a  lib/libLLVMTextAPI.a  lib/libclangLex.a  lib/libclangBasic.a  lib/libLLVMCore.a  lib/libLLVMRemarks.a  lib/libLLVMBitstreamReader.a  lib/liblldbUtility.a  -lws2_32  -lrpcrt4  lib/libLLVMMCDisassembler.a  lib/libLLVMMC.a  lib/libLLVMBinaryFormat.a  lib/libLLVMDebugInfoCodeView.a  lib/libLLVMDebugInfoMSF.a  lib/libLLVMSupport.a  lib/libLLVMDemangle.a  -lpsapi  -lshell32  -lole32  -luuid  -ladvapi32  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && :
lld-link: error: undefined symbol: __declspec(dllimport) PyLong_FromLong
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(_object* SBTypeToSWIGWrapper<unsigned int>(unsigned int*))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced 850 more times

lld-link: error: undefined symbol: __declspec(dllimport) _PyObject_New
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_Malloc
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SwigPyObject_dealloc(_object*))

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_Init
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SwigPyObject_dealloc(_object*))

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_Call
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))

lld-link: error: undefined symbol: __declspec(dllimport) PyUnicode_FromString
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced 5 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_SetAttr
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_GenericGetAttr
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced 7 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyType_Ready
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced 6 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyTuple_New
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SwigPyClientData_New(_object*))
>>> referenced by liblldbPluginScriptInterpreterPython.a(PythonDataObjects.cpp.obj):(lldb_private::python::PythonTuple::PythonTuple(lldb_private::python::PyInitialValue))
>>> referenced 3 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyDict_New
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(PyInit__lldb)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_pchar_descriptor())
>>> referenced 2 more times

lld-link: error: undefined symbol: __declspec(dllimport) _Py_NoneStruct
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(SWIG_Python_NewPointerObj(_object*, void*, swig_type_info*, int))
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 931 more times

lld-link: error: undefined symbol: __declspec(dllimport) Py_IsInitialized
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced 831 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyObject_CallFunction
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPython_CalculateNumChildren)
>>> referenced 5 more times

lld-link: error: undefined symbol: __declspec(dllimport) _Py_FalseStruct
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSWIGPythonCallThreadPlan)
>>> referenced 1 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyErr_Occurred
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 581 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyExc_SystemExit
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 17 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyErr_ExceptionMatches
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 17 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyErr_Print
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 34 more times

lld-link: error: undefined symbol: __declspec(dllimport) PyErr_Clear
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonWatchpointCallbackFunction)
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonCallTypeScript)
>>> referenced 534 more times

lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to see all errors)
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
[63/294] Building CXX object tools/llvm-exegesis/lib/X86/CMakeFiles/LLVMExegesisX86.dir/Target.cpp.obj
ninja: build stopped: subcommand failed.
osboxes@osboxes ~/g/llvm-mingw (master) [1]> ls /home/osboxes/python-cmake-install/libs/libpython36.a
/home/osboxes/python-cmake-install/libs/libpython36.a

I checked the link list above and libpython36.a is present (note the ls command just above). I checked the achitecture of the python.exe and the object files and they both report as x86_64. I checked various missing symbols and they seem to be present in the archive:

osboxes@osboxes ~/p/libs> pwd
/home/osboxes/python-cmake-install/libs
osboxes@osboxes ~/p/libs> file ../bin/python.exe 
../bin/python.exe: PE32+ executable (console) x86-64, for MS Windows
osboxes@osboxes ~/p/libs> ar -x libpython36.a longobject.c.obj
osboxes@osboxes ~/p/libs> file longobject.c.obj 
longobject.c.obj: Intel amd64 COFF object file, not stripped, 27 sections, symbol offset=0x47093, 240 symbols
osboxes@osboxes ~/p/libs> llvm-nm libpython36.a | grep "T PyTuple_New"
00000090 T PyTuple_New
osboxes@osboxes ~/p/libs> llvm-nm libpython36.a | grep "T PyObject_GenericGetAttr"
00001620 T PyObject_GenericGetAttr

That covers all my usual linking mistakes so I'm out of ideas?

[mstorsjo]

This came painfully close to succeeding but ended on this error:

lld-link: error: undefined symbol: __declspec(dllimport) PyErr_Clear
>>> referenced by tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/LLDBWrapPython.cpp.obj:(LLDBSwigPythonBreakpointCallbackFunction)

I checked the link list above and libpython36.a is present (note the ls command just above). I checked the achitecture of the python.exe and the object files and they both report as x86_64. I checked various missing symbols and they seem to be present in the archive:

osboxes@osboxes ~/p/libs> pwd
/home/osboxes/python-cmake-install/libs
osboxes@osboxes ~/p/libs> file ../bin/python.exe 
../bin/python.exe: PE32+ executable (console) x86-64, for MS Windows
osboxes@osboxes ~/p/libs> ar -x libpython36.a longobject.c.obj
osboxes@osboxes ~/p/libs> file longobject.c.obj 
longobject.c.obj: Intel amd64 COFF object file, not stripped, 27 sections, symbol offset=0x47093, 240 symbols
osboxes@osboxes ~/p/libs> llvm-nm libpython36.a | grep "T PyTuple_New"
00000090 T PyTuple_New
osboxes@osboxes ~/p/libs> llvm-nm libpython36.a | grep "T PyObject_GenericGetAttr"
00001620 T PyObject_GenericGetAttr

The problem is that the caller (in lldb) expects to link against the python APIs via dllimport (see the lld errors above), while libpython36.a provides them statically. If you do a similar llvm-nm+grep on the lldb object files, you'd see that they have undefined references to e.g. __imp_ PyErr_Clear, not against PyErr_Clear.

So the lldb build expects to link against e.g. libpython36.dll.a or what the corresponding import library for a DLL is called. Or you'd need to maybe set some define while building LLDB, to make it expect to consume the python API without dllimport (a define that disables the __declspec(dllimport) bits in the public Python headers.

[RussellHaley]

And it might allow us to build Python using the usual autotools build system as well. Patches can be downloaded on the fly with a sparse checkout of the Mingw-w64 packages repo. However, going with this approach requires using autoreconf to regenerate the configure script, which requires Perl. But if @mstorsjo is ok with it then we should continue with that approach, since the CMake build system has suffered from severe rotting.

I don't want to admit it yet, but I think you're right. I've managed to scoot around the "copysign" issue. I was hoping to get the cmake build working for the sake of the experience: I want to learn how the output configuration files from a cmake build are used. But I am nowhere near that at the moment. I don't mind picking at this in parallel for a little longer. :-)

[mstorsjo]

And it might allow us to build Python using the usual autotools build system as well. Patches can be downloaded on the fly with a sparse checkout of the Mingw-w64 packages repo. However, going with this approach requires using autoreconf to regenerate the configure script, which requires Perl. But if @mstorsjo is ok with it then we should continue with that approach, since the CMake build system has suffered from severe rotting.

I think the docker images I'm using for building do contain autoreconf and perl, so that shouldn't be a blocker I think. Other than that, I don't think I've said I've committed to including this - but if it turns out manageable I'll consider it at least.

Overall, I'd like to see patches moving upstream, but I'm not familiar with what the situation is wrt python vs mingw overall and why it still can't be built without custom patches - and I guess resolving that situation probably is a bit out of scope for this thread :-)

[longnguyen2004]

Overall, I'd like to see patches moving upstream, but I'm not familiar with what the situation is wrt python vs mingw overall and why it still can't be built without custom patches - and I guess resolving that situation probably is a bit out of scope for this thread :-)

There have been attempts to get the patches upstream (see https://bugs.python.org/issue17605, ~7 years ago), but for some reasons it's not accepted. For the time being, getting the patches from the packages repo is the only way.

[longnguyen2004]

I'm also thinking about making patches that would not require autoreconf (patches on the configure script directly), but that means we'll have to maintain the patches ourselves, which will increase development burden. All in all, building Python will most certainly require some patching, since Python wasn't designed with MinGW in mind.

[mstorsjo]

I'm also thinking about making patches that would not require autoreconf (patches on the configure script directly), but that means we'll have to maintain the patches ourselves, which will increase development burden.

Nah, I prefer patching the autotools source files and rerunning autoreconf in cases like these, the patches of autogenerated files are kinda messy...

[RussellHaley]

Cmake-python-buildsystem offers a flag for a shared library. As I was looking at the options, I remembered KDevelop needs the extensions built in so I turned that on as well:

cmake -G"Ninja" \
-DCMAKE_TOOLCHAIN_FILE="~/x86_64-w64-mingw32.cmake" \
-DCMAKE_INSTALL_PREFIX="/home/osboxes/python-cmake-install" \
-DCOMPILERPATH="/home/osboxes/llvm-mingw-host/bin/"  \
-DBUILD_EXTENSIONS_AS_BUILTIN=ON \
-DBUILD_LIBPYTHON_SHARED=ON \
..

I've had to fight through a bunch of new errors and I had to re-build the cmake for libffi (foreign function interface). I had to hack it because the CMAKE_SYSTEM_PROCESSOR variable isn't working correctly in the cmake files. I'll sort that out soon and update my fork. Here are my latest build errors (not that they mean anything to you). My asm compiler seems to be failing. I have included the cmake toolchain file below.

osboxes@osboxes ~/g/p/build-ninja-windows (py3.6.7-mingw-patch) [1]> ninja
[1/49] Building ASM_MASM object CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/libmpdec/vcdiv64.asm.obj
FAILED: CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/libmpdec/vcdiv64.asm.obj 
/home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-gcc
clang-11: error: no input files
[2/49] Building C object CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/_decimal.c.obj
FAILED: CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/_decimal.c.obj 
/home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-gcc -DNDEBUG -DPy_BUILD_CORE -Dlibpython_shared_EXPORTS -DANSI -DCONFIG_64 -DMASM -D_CRT_SECURE_NO_WARNINGS -I../Python-3.6.7/Include -I../cmake/config-mingw -I../Python-3.6.7/Python -I../Python-3.6.7/Modules/_ctypes/libffi/src/x86 -I../Python-3.6.7/Modules/_ctypes/libffi/include -I../Python-3.6.7/Modules/_ctypes/libffi_mingw -I../Python-3.6.7/Modules/_ctypes/libffi_mingw/include -I../Python-3.6.7/Modules/_decimal/libmpdec -I../Python-3.6.7/Modules/expat -I../Python-3.6.7/Modules/zlib -Wall -g -O3 -DNDEBUG -MD -MT CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/_decimal.c.obj -MF CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/_decimal.c.obj.d -o CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_decimal/_decimal.c.obj -c ../Python-3.6.7/Modules/_decimal/_decimal.c
../Python-3.6.7/Modules/_decimal/_decimal.c:4522:6: error: "No valid combination of CONFIG_64, CONFIG_32 and _PyHASH_BITS"
    #error "No valid combination of CONFIG_64, CONFIG_32 and _PyHASH_BITS"
     ^
../Python-3.6.7/Modules/_decimal/_decimal.c:4575:43: error: use of undeclared identifier 'p'
        mpd_qpowmod(exp_hash, &ten, tmp, &p, &maxctx, &status);
                                          ^
../Python-3.6.7/Modules/_decimal/_decimal.c:4580:32: error: use of undeclared identifier 'inv10_p'
        mpd_qpowmod(exp_hash, &inv10_p, tmp, &p, &maxctx, &status);
                               ^
../Python-3.6.7/Modules/_decimal/_decimal.c:4580:47: error: use of undeclared identifier 'p'
        mpd_qpowmod(exp_hash, &inv10_p, tmp, &p, &maxctx, &status);
                                              ^
../Python-3.6.7/Modules/_decimal/_decimal.c:4595:25: error: use of undeclared identifier 'p'
    mpd_qrem(tmp, tmp, &p, &maxctx, &status);
                        ^
5 errors generated.
[4/49] Building C object CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/callproc.c.obj
FAILED: CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/callproc.c.obj 
/home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-gcc -DNDEBUG -DPy_BUILD_CORE -Dlibpython_shared_EXPORTS -DX86_WIN32 -I../Python-3.6.7/Include -I../cmake/config-mingw -I../Python-3.6.7/Python -I../Python-3.6.7/Modules/_ctypes/libffi/src/x86 -I../Python-3.6.7/Modules/_ctypes/libffi/include -I../Python-3.6.7/Modules/_ctypes/libffi_mingw -I../Python-3.6.7/Modules/_ctypes/libffi_mingw/include -I../Python-3.6.7/Modules/_decimal/libmpdec -I../Python-3.6.7/Modules/expat -I../Python-3.6.7/Modules/zlib -Wall -g -O3 -DNDEBUG -MD -MT CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/callproc.c.obj -MF CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/callproc.c.obj.d -o CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/callproc.c.obj -c ../Python-3.6.7/Modules/_ctypes/callproc.c
../Python-3.6.7/Modules/_ctypes/callproc.c:718:13: warning: implicit declaration of function 'can_return_struct_as_int' is invalid in C99 [-Wimplicit-function-declaration]
        if (can_return_struct_as_int(dict->ffi_type_pointer.size))
            ^
../Python-3.6.7/Modules/_ctypes/callproc.c:720:18: warning: implicit declaration of function 'can_return_struct_as_sint64' is invalid in C99 [-Wimplicit-function-declaration]
        else if (can_return_struct_as_sint64 (dict->ffi_type_pointer.size))
                 ^
../Python-3.6.7/Modules/_ctypes/callproc.c:807:15: error: assigning to 'int' from incompatible type 'void'
        delta =
              ^
2 warnings and 1 error generated.
[6/49] Building C object CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/_ctypes.c.obj
FAILED: CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/_ctypes.c.obj 
/home/osboxes/llvm-mingw-host/bin/x86_64-w64-mingw32-gcc -DNDEBUG -DPy_BUILD_CORE -Dlibpython_shared_EXPORTS -DX86_WIN32 -I../Python-3.6.7/Include -I../cmake/config-mingw -I../Python-3.6.7/Python -I../Python-3.6.7/Modules/_ctypes/libffi/src/x86 -I../Python-3.6.7/Modules/_ctypes/libffi/include -I../Python-3.6.7/Modules/_ctypes/libffi_mingw -I../Python-3.6.7/Modules/_ctypes/libffi_mingw/include -I../Python-3.6.7/Modules/_decimal/libmpdec -I../Python-3.6.7/Modules/expat -I../Python-3.6.7/Modules/zlib -Wall -g -O3 -DNDEBUG -MD -MT CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/_ctypes.c.obj -MF CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/_ctypes.c.obj.d -o CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/_ctypes/_ctypes.c.obj -c ../Python-3.6.7/Modules/_ctypes/_ctypes.c
../Python-3.6.7/Modules/_ctypes/_ctypes.c:300:3: error: SIZEOF__BOOL has an unexpected value
# error SIZEOF__BOOL has an unexpected value
  ^
../Python-3.6.7/Modules/_ctypes/_ctypes.c:380:55: warning: format specifies type 'int' but the argument has type 'Py_ssize_t' (aka 'long long') [-Wformat]
                sprintf(buf, "%"PY_FORMAT_SIZE_T"d,", shape[k]);
                              ~~~~~~~~~~~~~~~~~~~~    ^~~~~~~~
                              %zd
../Python-3.6.7/Modules/_ctypes/_ctypes.c:382:55: warning: format specifies type 'int' but the argument has type 'Py_ssize_t' (aka 'long long') [-Wformat]
                sprintf(buf, "%"PY_FORMAT_SIZE_T"d)", shape[k]);
                              ~~~~~~~~~~~~~~~~~~~~    ^~~~~~~~
                              %zd
2 warnings and 1 error generated.
[7/49] Building C object CMakeBuild/libpython/CMakeFiles/libpython-shared.dir/__/__/Python-3.6.7/Modules/expat/xmltok.c.obj
ninja: build stopped: subcommand failed.

SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_CROSSCOMPILING 1)
SET(CMAKE_C_COMPILER ${COMPILERPATH}x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER ${COMPILERPATH}x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER ${COMPILERPATH}x86_64-w64-mingw32-windres)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

if(CMAKE_COMPILER_IS_GNUCC OR "${CMAKE_C_COMPILER_ID}" STREQUAL "Intel")
  if(COMPILER_HAS_FPIC)
    # when used in shared libraries, -fPIC is required by several architectures
    # and platforms (observed on AMD64, Solaris/Sparc).
    # we enable it per default here.
    add_definitions("-fPIC")
  endif()
  # enable gcc as front-end to assembler for .S files
  set(CMAKE_ASM_COMPILER "${CMAKE_C_COMPILER}")
  set(CMAKE_ASM_COMPILER_ARG1 "${CPPFLAGS} -c")
  enable_language(ASM)
elseif(CMAKE_COMPILER_IS_CLANG)
elseif("${CMAKE_C_COMPILER_ID}" STREQUAL "SunPro")
  set(CMAKE_ASM_COMPILER "${CMAKE_C_COMPILER}")
  set(CMAKE_ASM_COMPILER_ARG1 "${CPPFLAGS} -c")
  enable_language(ASM)
else()
  if (CMAKE_C_COMPILER_ID STREQUAL "Clang")
  if(COMPILER_HAS_FPIC)
    add_definitions("-fPIC")
  endif()
  # enable gcc as front-end to assembler for .S files
  set(CMAKE_ASM_COMPILER "${CMAKE_C_COMPILER}")
  set(CMAKE_ASM_COMPILER_ARG1 "${CPPFLAGS} -c")
  enable_language(ASM)
  endif()
endif()

SET(CMAKE_ASM_MASM_COMPILE_OBJECT ${CMAKE_ASM_COMPILER})

[mstorsjo]

FWIW, it might be easier to find a define for disabling dllimport, if one is going to be linking statically, than to get the cmake based build working, if it's broken/unmaintained.

Then on the other hand, I don't know if python on windows actually is supposed to work when linked statically at all.

[longnguyen2004]

@RussellHaley At this point I think it'd be better if we just go with the autotools build system, since the MSYS2 folks have done a huge effort to make it work and keep it up to date (3.8.7 at the time of this comment). The only problem is that we would have to maintain the patch list, but that's still better than the horribly outdated CMake build system.

[RussellHaley]

Okay, I concede. :-)

[RussellHaley]

To use the MSYS2 patches we would have to import the build scripts as well: https://www.msys2.org/wiki/Creating-Packages/

Hmmm... lilypond music software (http://lilypond.org/) cross compiles python: https://bugs.python.org/issue1597850 . They tried to push patches for years.

Lillypond just had a release. I've signed up for their dev mailing list and I'll ask them if they have current patches. (I'll also download their source code and check).

[RussellHaley]

Oh, maybe not. I thought they were doing something "fancy", but I suppose we can just read in all the patches using a script? hmmm... We could also dump the patches together in one file too...

[RussellHaley]

Ooooh... MSYS2 has patches for cppcheck...

https://github.com/msys2/MINGW-packages

[mstorsjo]

The problem is that the caller (in lldb) expects to link against the python APIs via dllimport (see the lld errors above), while libpython36.a provides them statically. If you do a similar llvm-nm+grep on the lldb object files, you'd see that they have undefined references to e.g. __imp_ PyErr_Clear, not against PyErr_Clear.

So the lldb build expects to link against e.g. libpython36.dll.a or what the corresponding import library for a DLL is called. Or you'd need to maybe set some define while building LLDB, to make it expect to consume the python API without dllimport (a define that disables the __declspec(dllimport) bits in the public Python headers.

So, if you had a working build using autotools, and but it's failing due to wanting to link python as a DLL, didn't you get a dll and libpyhon*.dll.a when you built it? If not, can you try adding --enable-shared when building python?

Judging from the upstream, unpatched code at least, https://github.com/python/cpython/blob/master/Include/pyport.h#L666-L701, it looks like it defaults to dllimport as long as Py_ENABLE_SHARED is defined by the pyconfig.h. (Oddly enough, it switches to dllexport if Py_ENABLE_SHARED isn't defined, which certainly would be a bit unexpected too, as it would make e.g. liblldb export the python API - but maybe that's handled somewhere in the patches?)

So, in a successful autotools build, did you get any DLL and corresponding libpython*.dll.a, and/or does pyconfig.h contain Py_ENABLE_SHARED?

[mstorsjo]

Or does the patched autotools build end up using the hardcoded PC/pyconfig.h (which is primarily intended for use with MSVC where one doesn't run configure at all)? That one does define Py_ENABLE_SHARED unless Py_NO_ENABLE_SHARED was defined by the caller.