# Superbuild Python version riddles
**URL:** https://discourse.paraview.org/t/superbuild-python-version-riddles/619
**Category:** Development
**Created:** [September 23, 2018, 10:03am UTC](https://discourse.paraview.org/t/superbuild-python-version-riddles/619 "2018-09-23T10:03:27Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [September 23, 2018, 10:03am UTC](https://discourse.paraview.org/t/superbuild-python-version-riddles/619/1 "2018-09-23T10:03:28Z")
Again talking about the superbuild I am working with, now still with MSVC2013, PV 5.5.0 and adapted Qt5.9.1, and working with Python 2.7.
The superbuild goes through, but during the packaging I am getting the following message:
Failed to install pvdataserver:
Traceback
[…]
RuntimeError: Unable to find the api-ms-win-core-rtlsupport-l1-1-0.dll library from […]
For me this looks like some Windows and/or MSC version issue, and the one thing that I really find is the fact that Python does not really look like being compiled with the same toolset that I am otherwise using:
The installed system Python tells the following on starting the console:
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32
Also there is a newly compiled Python in my superbuild which tells me the following on startup:
Python 2.7.3 (default, Feb 14 2017, 14:49:11) [MSC v.1500 64 bit (AMD64)] on win32
What bothers me most is the fact that MSC v.1500 must be according to Wikipedia:
MSVC++ 9.0 \_MSC\_VER 1500 (Visual Studio 2008 version 9.0)
What I would rather expect with my actual MSVC would be version 1800!
Is this a known problem? In any case it looks weird for me that I find that “old” version of Python in the folder where I would expect the newly compiled stuff from the superbuild:
…/superbuild/python/src/bin/python.exe
(Although strange enough: this python.exe has a date/time stamp of 14/02/2017 - not really the time when my superbuild was running…
On the other hand: My initial error message did not tell me anything about Python, but about the pvdataserver…
Regards,
Cornelis
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [September 23, 2018, 12:07pm UTC](https://discourse.paraview.org/t/superbuild-python-version-riddles/619/2 "2018-09-23T12:07:48Z")
> [@cobo](#):
>
> RuntimeError: Unable to find the api-ms-win-core-rtlsupport-l1-1-0.dll library from […]
To fix this, you’d need these changes:
[https://gitlab.kitware.com/paraview/common-superbuild/merge\_requests/242/diffs](https://gitlab.kitware.com/paraview/common-superbuild/merge_requests/242/diffs)
Essentially, the rules needed to be updated to not try to package these system files. These changes are already in for 5.6.
I am going to defer the Python question to @ben.boeckel.
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [September 23, 2018, 4:17pm UTC](https://discourse.paraview.org/t/superbuild-python-version-riddles/619/3 "2018-09-23T16:17:54Z")
Great - with this the package was successfully generated! Tomorrow I will certainly try to install them and run the software.
More precisely: I first applied the indicated patches, but it was already clear that I was not starting with exactly the right version. The result was some indentation error.
However, the “radical solution” - just replace the entire fixup.bundle.windows.py - made it finally happen.
Bottom line: The initial problem was obviously not a Python problem, but tomorrow I will try to find out which of the Python.exe was actually installed by the NSIS package…
Regards, Cornelis
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [September 26, 2018, 2:33pm UTC](https://discourse.paraview.org/t/superbuild-python-version-riddles/619/4 "2018-09-26T14:33:17Z")
> [@cobo](#):
>
> What bothers me most is the fact that MSC v.1500 must be according to Wikipedia:
>
> MSVC++ 9.0 \_MSC\_VER 1500 (Visual Studio 2008 version 9.0)
Python2 only supports being compiled with the VS2008 toolchain (MSVC 9.0; yes the version numbering scheme for MSVC, VS, etc. is convoluted), so that’s expected. Because “no one” has such a toolchain laying around anymore, we just compile a Python here and ship that as a binary drop (it’s made with the `prebuilt-python` project in the `common-superbuild` for those curious).