Efforts to support MSVC 14.0

Norbert Thiebaud nthiebaud at gmail.com
Mon Sep 7 06:11:39 PDT 2015

On Mon, Sep 7, 2015 at 1:43 AM, David Ostrovsky <d.ostrovsky at gmx.de> wrote:
> As you may know there are efforts underway: [1] to support MSVC 14.0.
> After fixing around 20 external libraries and some core places to
> support new compiler, the code can be (more or less) compiled. The tests
> are failing because of EH issue in uno bridge (more on this below).
> I have a couple of questions:
> * Support UCRT, SDK 10 and .NET 4.6 is quite intrusive change: [2] and
> no wonder, that it's pending for review for months now... nevertheless
> if /me don't see any objections, i will merge this change next week.

Well as long as it does not regress _existing_ platform no problem.

> * Python 3.5 upgrade is needed to support new compiler: [3]. I don't
> have access to Mac OS X atm. Can someone check why Jenkins job on this
> platform is failing: [4]? Moreover new Python release has announced to
> discontinue support for older MS compilers (VS 2013). We never dropped
> support for older compiler during introduction of a new one, right? Or
> would this be a option?

No that is not an option.
having a 'jump over the cliff' commit is just not manageable from a ci
perspective.. not to mention for every other person that currently
build for windows.
We need to have vs 2015 committed and working and then we will migrate
some of the tinderbox, to cover both for a while to avoid bit-rot
and then with enough advance notice to everyone we can consider making
vs2015 a pre-req.
Bearing in mind that this should not be backported to 5.0 or 4.4... so
we will keep vs2013 until at least 5.0 goes out of service.

>Can someone check why Jenkins job on this
platform is failing: [4]?

If fails because python3/Mac/Makefile.in has changed and does not
install pythonw in the framework anymore.
" pythonw is used to run python scripts that may display a graphical
user interface (GUI).  Pass the same
     arguments to pythonw as you would to python(1).  For executable
scripts, use pythonw in the "#!" line.

     Actually, since Python 2.5, the normal python also allows GUI
access, so python and pythonw are now
btw that is why the patch names should reflect the version they are
actually patching iow if you need to modify
python-3.3.0-darwin.patch.1 because it does not apply on 3.3.5 it
should really be called pythin-3.3.5-darwin.patch1

anyhow: you need

diff --git a/external/python3/ExternalProject_python3.mk
index 29179d5..2f9434d 100644
--- a/external/python3/ExternalProject_python3.mk
+++ b/external/python3/ExternalProject_python3.mk
@@ -139,7 +139,7 @@ $(call
gb_ExternalProject_get_state_target,python3,executables) : $(call
        cd $(python3_fw_prefix)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/bin
; \
        for file in python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR) \
                    python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)m \
+                   ; do \
        $(INSTALL_NAME_TOOL) -change \

                @executable_path/../LibreOfficePython $$file ; done

and, not related to pytonw, but you also need

diff --git a/pyuno/source/module/pyuno.cxx b/pyuno/source/module/pyuno.cxx
index 9e9274ab..7d19b9b 100644
--- a/pyuno/source/module/pyuno.cxx
+++ b/pyuno/source/module/pyuno.cxx
@@ -1610,6 +1610,8 @@ static PyNumberMethods PyUNONumberMethods[] =
     nullptr,                                         /*
nb_inplace_true_divide */

     nullptr,                                         /* nb_index */
+    nullptr,                                         /* nb_matrix_multiply */
+    nullptr                                          /*
nb_inplace_matrix_multiply */

In general when upgrading python you want to keep an eye on
PyNumberMethods and other stuff in
as pyuno depend on it...


More information about the LibreOffice mailing list