This is an automated email from the ASF dual-hosted git repository. leginee pushed a commit to branch win10-msvc-trunk in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit c73ac1434d3a2c0c44e5903991c4e6db0bc45255 Author: Peter Kovacs <[email protected]> AuthorDate: Sun Aug 23 00:00:47 2026 +0200 win64: find ml64.exe, and name _freeze_module explicitly Two x64 build fixes that were already in the working tree before this session; committing them here so the branch reproduces the build that was actually tested. configure.ac: the 64 bit assembler is a different binary, not a different copy. ml.exe emits 32 bit objects, ml64.exe 64 bit ones, and the x64 toolset directory ships only the latter, so probe for whichever matches BUILD_WIN64 instead of always looking for ml.exe. python/makefile.mk: name _freeze_module explicitly, and first. Relying on pythoncore's ProjectReference to pull it in happens to work for Win32 and does not for x64 -- the x64 build ran without _freeze_module ever being invoked, left Python/frozen_modules holding nothing but its README, and then died a long way from the cause: getpath.c(22): fatal error C1083: cannot open include file '../Python/frozen_modules/getpath.h' Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01VrM7EMKgiuyVcCUe9nSbZR --- main/configure.ac | 21 +++++++++++++++------ main/python/makefile.mk | 17 +++++++++++++---- 2 files changed, 28 insertions(+), 10 deletions(-) diff --git a/main/configure.ac b/main/configure.ac index 9168cbce59..759503d909 100644 --- a/main/configure.ac +++ b/main/configure.ac @@ -6411,17 +6411,26 @@ dnl *************************************** dnl testing ml.exe assembler path dnl *************************************** if test "$_os" = "WINNT" -a "$WITH_MINGWIN" != "yes"; then - AC_MSG_CHECKING([ml.exe assembler path]) + dnl The 64 bit assembler is a different BINARY, not just a different copy: + dnl ml.exe emits 32 bit objects and ml64.exe 64 bit ones, and the x64 + dnl toolset directory ships only the latter. Look for whichever one goes + dnl with the target being built. + if test "$BUILD_WIN64" = "TRUE" ; then + ASM_EXE_NAME=ml64.exe + else + ASM_EXE_NAME=ml.exe + fi + AC_MSG_CHECKING([$ASM_EXE_NAME assembler path]) if test -n "$with_asm_home"; then with_asm_home=`cygpath -u "$with_asm_home"` fi - if test ! -x "$with_asm_home/ml.exe"; then - AC_PATH_PROG(ML_EXE, ml.exe) + if test ! -x "$with_asm_home/$ASM_EXE_NAME"; then + AC_PATH_PROG(ML_EXE, $ASM_EXE_NAME) if test -z "$ML_EXE"; then - if test -x "$with_cl_home/bin/ml.exe"; then + if test -x "$with_cl_home/bin/$ASM_EXE_NAME"; then with_asm_home=$with_cl_home/bin AC_MSG_RESULT([found ($with_asm_home)]) - elif test -x "$with_cl_home/$cl_subdirectory/ml.exe"; then + elif test -x "$with_cl_home/$cl_subdirectory/$ASM_EXE_NAME"; then dnl A modern toolset keeps the assembler beside the compiler in the dnl split bin/Host<host>/<target> tree, and the target half matters: dnl the x86 directory has ml.exe, the x64 one has ml64.exe. Reusing @@ -6430,7 +6439,7 @@ if test "$_os" = "WINNT" -a "$WITH_MINGWIN" != "yes"; then with_asm_home=$with_cl_home/$cl_subdirectory AC_MSG_RESULT([found ($with_asm_home)]) else - AC_MSG_ERROR([Configure did not find ml.exe assembler.]) + AC_MSG_ERROR([Configure did not find $ASM_EXE_NAME assembler.]) fi else with_asm_home="ASM_IN_PATH" diff --git a/main/python/makefile.mk b/main/python/makefile.mk index 53b6384748..de800af8f9 100644 --- a/main/python/makefile.mk +++ b/main/python/makefile.mk @@ -184,10 +184,19 @@ BUILD_DIR=PCbuild # order: python.vcxproj declares one on _ctypes purely so that a developer # building 'python' in the IDE gets a usable interpreter. Going through the # solution therefore drags in libffi, which we do not have and do not want. -# A .vcxproj built directly honours its own ProjectReferences -- python still -# builds pythoncore first, and pythoncore still builds _freeze_module -- and -# ignores the solution's editorial ones. -PYTHON_PROJECTS=pythoncore python pythonw _socket select unicodedata pyexpat _elementtree _multiprocessing _overlapped _asyncio _queue _uuid _zoneinfo winsound _decimal _msi +# A .vcxproj built directly honours its own ProjectReferences and ignores the +# solution's editorial ones. +# +# _freeze_module is named EXPLICITLY, and first. Relying on pythoncore's +# reference to pull it in happens to work for Win32 and does not for x64: the +# x64 build ran without _freeze_module ever being invoked, left +# Python/frozen_modules holding nothing but its README, and then died a long +# way from the cause -- +# getpath.c(22): fatal error C1083: cannot open include file +# '../Python/frozen_modules/getpath.h' +# Naming it costs one project and does not depend on which references MSBuild +# decides to honour. +PYTHON_PROJECTS=_freeze_module pythoncore python pythonw _socket select unicodedata pyexpat _elementtree _multiprocessing _overlapped _asyncio _queue _uuid _zoneinfo winsound _decimal _msi # main/zlib's unpacked source, in the form MSBuild wants. Globbed rather than # spelled out so a zlib version bump does not silently miss it -- pythoncore
