Different (wrong?) MSVC version found in 46.0

[sspasweden]

Hi,

Upgrading from setuptools 45.2 to 46 I am having problem with it finding different versions of the msvc compiler. I am on Win10 with 32bit python 3.5.4.

Using setuptools 45.2, the following compiler path is used:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe

Using setuptools 46, the following compiler path is used:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\cl.exe

The latter ends up with the following error:

fatal error C1047: The object or library file '*.lib' was created with an older compiler than other objects; rebuild old objects and libraries

whereas the former works (and have worked for several years). The lib that is being linked is built with the msvc 14.0 compiler.

This seems to be related to #1904 . Is this change of behavior according to expectations?

It seems that even though the range of msvc 14.x compilers should be binary compatible, there are exceptions: https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019

The /GL flag restriction is probably what goes south here as it seems that setuptools enables this one by default?

A workaround (even though it is not very sustainable) is obviously to avoid updating setuptools.

[EccoTheFlintstone]

#2018 seems to be the same problem (don't have issue with 64bit python, and setuptools 45.2 works like a charm on 32 and 64bit)

[mayeut]

Not the same issue as #2018, msvc not found, whereas here, msvc is found but version has changed.

Same root cause for the issues #1904

setuptools does not set the /GL flag. This happens in distutils.

The behavior in setuptools is now consistent across CPython 3.5, 3.6, 3.7 & 3.8 and uses the most recent supported toolchain: the only "spec" and expectations I had when drafting #1904 was https://wiki.python.org/moin/WindowsCompilers

Is the library being linked in also uses /GL ? I would guess so and that removing /GL when building this library should allow linking. That's one workaround I'm thinking about.

The other workaround I can think about is to run from within a VC2015 command prompt and setting DISTUTILS_USE_SDK to a non-empty value (as mentioned in Distutils notes of https://wiki.python.org/moin/WindowsCompilers)

[jaraco]

By my quick research, /GL indicates "whole program optimization". That does seem like a useful feature to enable by default. If it's readily feasible, I'd suggest providing a mechanism to disable that build feature for cross-build compatibility.

Alternately, sspasweden, you have other options. You could rely on setuptools<46 until the linked libraries are built on MSVC 2017.