compile errors with pyicu 1.9.2 using visual studio community 2015 on windows 10 #7
Comments
|
Hmmm, "cannot convert argument 1 from 'UBool' to'UBool *(__cdecl *)(void)" I can't reproduce any of this as I don't have either version of Windows or Try the following:
Please, let us know what you find out. Andi.. On Sat, 10 Oct 2015, maveryKearney wrote:
|
|
I commented out the problematic code, and setup.py build completes without (hmmm I don't think I ran with "-debug", but hey this is a holiday.) From python (win32) I can import icu, which is good. I am proceeding to port all the stuff I need for my purposes. I am just using word break iteration, with luck I don't need this corner of Since it builds then I should be able test things, and see what is broken. I'll keep you posted. Thanks for the quick response. Do you have a up-down loadable version of vs 2010 express by chance? I actually don't think it is essential since I have debug capability on Mac Win 7 that will help. I was remiss in not backing up a version of VS 2010 for this situation, BUT there may not be a version that works on Windows 10. regards, -m From: ovalhub [mailto:notifications@github.com] Hmmm, "cannot convert argument 1 from 'UBool' to'UBool *(__cdecl *)(void)" I can't reproduce any of this as I don't have either version of Windows or Try the following:
Please, let us know what you find out. Andi.. On Sat, 10 Oct 2015, maveryKearney wrote:
Reply to this email directly or view it on GitHub |
|
Commenting out the problematic lines (andi's suggestion) in calendar.cpp enables the compilation to complete, for pycicu to build and install. In python, I can import icu and can run simple examples of what I need to work. Now to go back and build a debug version. I am wondering if I would see the same problem on Win 7, but there I have python 3.4.2, icu54, pyicu 1.9.2 and virtual c++ express 2010 I think. and that works. On Mac I have python 3.5.0, icu55, pyyicu 1.9.2 and whatever is standard there. My next step is to recompile icu with my tweaks, and see if the problem is critical to me. I suspect it is not, since icu is huge. I'll not know until I try. I'll also install vs community 2015 on my win 7 machine and see if I see the same problem over there. There was a compilation or link reason I stayed back at icu54 on win 7. I just can't remember what it was. It wasn't critical so I didn't worry about it. |
|
I've encountered the same problem on Windows 7, Python 3.5.1 64-bit, ICU 57.1, PyICU 1.9.2 and Visual Studio Community 2015. Commenting-out the 4 mentioned lines from On a side note, I've also had some problems with linking, but I've solved them by renaming |
I had an exactly same problemC:\ICU PY\dist\PyICU-1.9.3>pip install pyicu error: command 'C:\Program Files (x86)\Microsoft Visual Studio14.0\VC\BIN\x86_amd64\cl.exe' failed with exit status 2 |
|
I suspect that the local variable 'daylight' is clashing with some macro Look in calendar.cpp and rename all occurrences of 'daylight' to Thanks ! Andi.. On Fri, 19 Aug 2016, nirvichara wrote:
|
|
I don't have access to Windows or this compiler. |
|
i have the same calendar.cpp issue on 1.9.5, building for Python 3.5.3 Win32, with freshly built Win32 ICU 58.2 on x64 Windows 7 using VS 2015 MSBuild. and after commenting out those 4 calendar.cpp lines, and explicit cast in common.cpp line 226 of the first argument with: u_memcpy((UChar *) PyUnicode_2BYTE_DATA(result), utf16, len16); |
|
On Sat, 28 Jan 2017, SebastianKnight wrote:
i have the same calendar.cpp issue on 1.9.5, building for Python 3.5.3
Win32, with freshly built Win32 ICU 58.2 on x64 Windows 7 using VS 2015
MSBuild.
I suspect that there is a macro in VC++ that clobbers the 'daylight'
variable around line 362 in calendar.cpp with something incompatible. Can
you please try renaming 'daylight' to something else everywhere in
calendar.cpp, recompile, and tell us if it that solves the problem ?
Thanks !
Andi..
…
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#7 (comment)
|
|
after the change of int daylight to int renamed it's still the same issues. here's the error thrown in calendar.cpp
|
|
On Sun, 29 Jan 2017, SebastianKnight wrote:
after the change of int daylight to int renamed it's still the same issues. here's the error thrown in calendar.cpp
`C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Ox
/W3 /GL /DNDEBUG /MD -Ic:/icu/include -IC:\Python35\include -IC:\Python35\inclu
de "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Prog
ram Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt" "-IC:\Program Files (
x86)\Windows Kits\8.1\include\shared" "-IC:\Program Files (x86)\Windows Kits\8.1
\include\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\winrt" "-IC:\Pro
gram Files (x86)\Microsoft Visual Studio 8\VC\include" "-IC:\Program Files (x86)
\Microsoft SDKs\Windows\v7.0A\Include" /EHsc /Tpcalendar.cpp /Fobuild\temp.win32
-3.5\Release\calendar.obj /Zc:wchar_t /EHsc /DPYICU_VER=\"1.9.5\"
calendar.cpp
calendar.cpp(362): error C2664: 'icu_58::UnicodeString &icu_58::TimeZone::getDis
playName(UBool *(__cdecl *)(void),icu_58::TimeZone::EDisplayType,const icu_58::L
ocale &,icu_58::UnicodeString &) const': cannot convert argument 1 from 'UBool'
to 'UBool *(__cdecl *)(void)'
calendar.cpp(362): note: Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
calendar.cpp(376): error C2664: 'icu_58::UnicodeString &icu_58::TimeZone::getDis
playName(UBool *(__cdecl *)(void),icu_58::TimeZone::EDisplayType,const icu_58::L
ocale &,icu_58::UnicodeString &) const': cannot convert argument 1 from 'UBool'
to 'UBool *(__cdecl *)(void)'
calendar.cpp(376): note: Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
calendar.cpp(381): error C2664: 'icu_58::UnicodeString &icu_58::TimeZone::getDis
playName(UBool *(__cdecl *)(void),icu_58::TimeZone::EDisplayType,const icu_58::L
ocale &,icu_58::UnicodeString &) const': cannot convert argument 1 from 'UBool'
to 'UBool *(__cdecl *)(void)'
calendar.cpp(381): note: Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
calendar.cpp(389): error C2664: 'icu_58::UnicodeString &icu_58::TimeZone::getDis
playName(UBool *(__cdecl *)(void),icu_58::TimeZone::EDisplayType,const icu_58::L
ocale &,icu_58::UnicodeString &) const': cannot convert argument 1 from 'UBool'
to 'UBool *(__cdecl *)(void)'
calendar.cpp(389): note: Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\
cl.exe' failed with exit status 2`
Well, that's strange. I can't make sense of this error.
It seems to be complaining that an int (UBool) is passed where a function
pointer UBool *(__cdecl *)(void) is expected.
The TimeZone::getDisplayName() method is documented to expect UBool:
http://icu-project.org/apiref/icu4c/classicu_1_1TimeZone.html
Since I can't reproduce it (no access to Windows compiler) there is not much
I can do. If you find a solution, please send in a patch :-)
Thanks !
Andi..
…
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#7 (comment)
|
|
when you compile using the /E switch to check the preprocessor output to standard output you can find these types being ex/imported: commenting out the last define in C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\time.h so that how about it... |
|
On Jan 30, 2017, at 18:20, SebastianKnight ***@***.***> wrote:
when you compile using the /E switch to check the preprocessor output to standard output you can find these types being ex/imported:
class __declspec(dllimport) TimeZone ... UnicodeString& getDisplayName(UBool (*__daylight()), EDisplayType style, UnicodeString& result) const; UnicodeString& getDisplayName(UBool (*__daylight()), EDisplayType style, const Locale& locale, UnicodeString& result) const;
then in "C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\time.h" is
__declspec(dllimport) int* __cdecl __daylight(void);
with following:
`// Nonzero if Daylight Savings Time is used
Check_return _CRT_INSECURE_DEPRECATE_GLOBALS(_get_daylight)
_ACRTIMP int* __cdecl __daylight(void);
#define _daylight (*__daylight())`
commenting out the last define in "C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\time.h" so that _daylight isn't obscured with that function pointer and rebuild without /E produces a clean build.
how about it...
So my first intuition was right. I had suggested renaming the 'daylight' variable in calendar.cpp but it's the icu header that triggers this VC bug.
A better fix might be to #undef the culprit macro in calendar.cpp before it hits the bug.
Could you provide a patch to this effect ?
Thank you for elucidating this !
Andi..
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
i've got to put both around the let me know if that bothers you in any way, now it's narrowed within and while at it, i've got to change in setup.py line 22 shall i patch that too? |
|
On Jan 31, 2017, at 04:26, SebastianKnight ***@***.***> wrote:
i'll check it out first, and while at it, i've got to change in setup.py line 22
ICU_VERSION = check_output(('icu-config', '--version')).strip()
to
ICU_VERSION = check_output(('icuinfo', '--version')).strip()
since icuinfo is a Windows utility.
So ICU uses a different name for icu-config on Windows ?
shall i patch that too?
Sure, but that's a separate issue.
Andi..
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
seems so, bin/ has no icu-config. |
|
please let me know if these are of no use to you. |
|
On Tue, 31 Jan 2017, SebastianKnight wrote:
please let me know if these are of no use to you.
[commits.zip](https://github.com/ovalhub/pyicu/files/743374/commits.zip)
Thank you for your patches. Here are some comments about them:
1. You seem to exclude the code that causes problems when _daylight is
defined:
+#if defined(_MSC_VER) && defined(_daylight)
+#undef _daylight
UnicodeString *u, _u;
int daylight;
Locale *locale;
TimeZone::EDisplayType type;
+#endif
or
+#if defined(_MSC_VER) && defined(_daylight)
+#undef _daylight
self->object->getDisplayName((UBool) daylight, type, _u);
+#endif
This is wrong as the code inside the #if / #endif bracket is going to be
missing for everyone but those satisfying the
defined(_MSC_VER) && defined(_daylight)
condition. Instead you must put the #endif right after the #undef and leave
all other code untouched.
For example:
+#if defined(_MSC_VER) && defined(_daylight)
+#undef _daylight
+#endif
UnicodeString *u, _u;
int daylight;
Locale *locale;
TimeZone::EDisplayType type;
The effect of #undef is good for the rest of the file (or until something
else redefines a _daylight macro). Thus, it is sufficient to add the
following only once near the top of the calendar.cpp file, after all
#include statements.
+#if defined(_MSC_VER) && defined(_daylight)
+#undef _daylight
+#endif
Please, try this and let me know if the problem remains fixed.
I'd fix this myself (thanks to your elucidating this) but I can't test it
since I don't have access to your version of the VC compiler.
So, please try my fix above and let me know if it stills solves the problem.
2. For the second patch, it's mostly correct except for the platform match
starting with 'win'. It's better to check that platform == 'win32' since
that is what is expected by the rest of setup.py anyway (all the
dictionaries keyed on platform have a 'win32' key.
Thank you !
Andi..
…
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#7 (comment)
|
|
thank you for explaining me that. but that gets me back where i was to begin with. the need for multiple undefs, and my guess may be wrong, comes from _daylight being defined again through the function body. and the need to wrap some code between undef and endif is obvious from the output. make it around the code it gets compiled, make it with undef/endif without a code between them doesn't. sorry for my empiricism. never mind, i somehow presumed you'll have no good use of the patch. i'll go on and make me a wheel. |
|
On Jan 31, 2017, at 17:18, SebastianKnight ***@***.***> wrote:
thank you for explaining me that. but that gets me back where i was to begin with.
That makes no sense. If your fix worked before, it should still work with #endif moved up so as to not exclude code for everyone else not running on Windows. As is, your patch excludes code for every one else.
You need to move the #endif just below the #undef, try that first. Then just include these three lines once near the top of the file *after* all the #include statements.
Andi..
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
top of the file, after includes, just for your piece of mind, doesn't give a result in a way you suggest. it's broken as it were before, just as with any other combination you suggested so far. |
|
On Jan 31, 2017, at 17:42, SebastianKnight ***@***.***> wrote:
top of the file, after includes, just for your piece of mind, doesn't give a result in a way you suggest. it's broken as it were before, just as with any other combination you suggested so far.
i narrowed the scope of their reach as minimal as i could. honest.
Then your original fix is wrong too. I suspect that you need to #undef daylight, not _daylight. I doubt the ICU developers named a function arg with a leading underscore.
Try this, after the #includes:
#if defined(daylight)
#error it is daylight
#elif defined(_daylight)
#error it is _daylight
#else
#error it is neither
#endif
What compiler error message do you get ?
Andi..
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
for that i got what you expected i would: undefining daylight at the top of the file, just like _daylight previously, produces the same compilation errors. any more ideas for me check upon, make me a list please, and zip it. |
|
On Jan 31, 2017, at 17:57, SebastianKnight ***@***.***> wrote:
for that i got what you expected i would:
calendar.cpp(33): fatal error C1189: #error: it is daylight
Ok, after the #include lines, just add one line:
#undef daylight
and remove all the other changes you made or start from a fresh calendar.cpp file.
Andi..
… undefining daylight at the top of the file, just like _daylight previously, produces the same compilation errors. any more ideas for me check upon, make me a list please, and zip it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
which one is more instructive of my possible neglect: start from a fresh file or remove all the other changes? sorry mate, i may not wash my dishes every day, but i start every trial with a clean, fresh, pristine file each time. your ideas don't work on Windows so far (not even the last one). i understand you. i don't like it either. but hey, mine worked. the list of further pearls, please, put in a zip. |
|
On Jan 31, 2017, at 18:28, SebastianKnight ***@***.***> wrote:
and remove all the other changes you made or start from a fresh calendar.cpp file.
which one is more instructive of my possible neglect: start from a fresh file or remove all the other changes? sorry mate, i may not wash my dishes every day, but i start every trial with a clean, fresh, pristine file each time.
your ideas don't work on Windows so far (not even the last one). i understand you. i don't like it either. but hey, mine worked. the list of further pearls, please, put in a zip.
Ok then, forget it, I'm out of ideas.
Thank you for trying !
Andi..
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On Tue, 31 Jan 2017, SebastianKnight wrote:
> and remove all the other changes you made or start from a fresh calendar.cpp file.
which one is more instructive of my possible neglect: start from a fresh file or remove all the other changes? sorry mate, i may not wash my dishes every day, but i start every trial with a clean, fresh, pristine file each time.
your ideas don't work on Windows so far (not even the last one). i
understand you. i don't like it either. but hey, mine worked. the list of
further pearls, please, put in a zip.
Ah, wait, I gave you bad instructions. The '#undef daylight' line must be
inserted after the place that defines the macro, presumably some of the MSVC
includes files, but *before* the ICU header file that defines the
TimeZone::getDisplayName() function.
Basically, you want the 'daylight' symbol to be left untouched. We've
already determined that there is a macro called 'daylight' that causes
trouble. Now, we must neuter it before it causes more damage, ie, before
ICU's timezone.h file is included (or maybe ICU's simpletz.h, include just
after it in common.h).
But, still guessing here, given that other ICU header files may include
timezone.h before common.h gets a change to do so, it might be better to
#undef daylight
before the first #include <unicode/....h> file, in my version that is
#include <unicode/utypes.h>
at line 90 in common.h.
I attached a common.h.patch file to this message to illustrate what I mean.
Andi..
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#7 (comment)
Index: common.h
===================================================================
--- common.h (revision 102)
+++ common.h (working copy)
@@ -87,6 +87,11 @@
# endif
#endif
+/* apparently a macro defined by some versions of the MSVC compiler */
+#ifdef daylight
+#undef daylight
+#endif
+
#include <unicode/utypes.h>
#include <unicode/unistr.h>
#include <unicode/ucnv.h>
|
|
my kind fellow, i don't want anything. i got what i need. i even made a patch for others to see how i got there. you asked for a patch, you didn't understand the way it worked, and you need assistance for the next batch of ideas. good luck, s |
|
Managed to build after applying the above fix, with icu 58 on win64 / python 3.6 and created a wheel if it can be of use for anyone : |
|
I added: |
|
_daylight is what works, since that's a MS macro found in their time.h as explained above.
daylight as also explained above doesn't help. |
|
https://github.com/ovalhub/pyicu/pull/46/files at that exact location works. Tested on my system. |
The problem occurs with:
- visual studio community 2015
- windows 10 amd64 4-processor dell
- python 3.5.0 win32 python. Note that vc 2015 compiles amd64 bit code but blocks execution at run-time.
- icu 55 and 56 win32 builds
The problem does not occur when I use visual C++ 2010 express, I just verified this on my win7 machine. BUT
- unfortunately I no longer have the vs 2010 express install package,
- I can no longer find a means to download visual C++ 2010 express from a credible site. If I can't get it from microsoft directly then I probably don't want it, and MS probably is discouraging use
at this point.
- documentation for VS community 2015 indicates that visual C++ express 2010 is accessible "in" VS community 2015. I have not figured out how at this point.
Regardless it appears that python 3.5.0 is now using VS 2015 in production to compile from source.
Here is my compile output (I tried attaching but git hub declared, "Something went really wrong...")
It occurs to me that I should try installing VS 2015 on my win7 machine to see if by chance the compilation works there.
There are 4 instances of a single type error in a function/method within the pyicu calendar.cpp module
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2>C:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\PCbuild\win32\python.exe setup.py build --debug
C:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\PCbuild\win32\python.exe setup.py build --debug
running build
running build_py
running build_ext
building '_icu' extension
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Od /MDd /Zi /W3 /D_DEBUG -IC:\Users\xxxxxx\bryllyg\opt\icu\56.1\icu\include -IC:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\include -IC:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\PC "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\include\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\shared" "-IC:\Program Files (x86)\Windows Kits\8.1\include\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\winrt" /EHsc /Tpc:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\bases.cpp /Fobuild\temp.win32-3.5\Debug\bases.obj /Zc:wchar_t /EHsc /DPYICU_VER="1.9.2" /Od /DDEBUG
bases.cpp
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Od /MDd /Zi /W3 /D_DEBUG -IC:\Users\xxxxxx\bryllyg\opt\icu\56.1\icu\include -IC:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\include -IC:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\PC "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\include\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\shared" "-IC:\Program Files (x86)\Windows Kits\8.1\include\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\winrt" /EHsc /Tpc:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp /Fobuild\temp.win32-3.5\Debug\calendar.obj /Zc:wchar_t /EHsc /DPYICU_VER="1.9.2" /Od /DDEBUG
calendar.cpp
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(353): error C2664: 'icu_56::UnicodeString &icu_56::TimeZone::getDisplayName(UBool *(__cdecl *)(void),icu_56::TimeZone::EDisplayType,const icu_56::Locale &,icu_56::UnicodeString &) const': cannot convert argument 1 from 'UBool' to 'UBool *(__cdecl *)(void)'
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(353): note: Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(367): error C2664: 'icu_56::UnicodeString &icu_56::TimeZone::getDisplayName(UBool *(__cdecl *)(void),icu_56::TimeZone::EDisplayType,const icu_56::Locale &,icu_56::UnicodeString &) const': cannot convert argument 1 from 'UBool' to 'UBool *(__cdecl *)(void)'
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(367): note: Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(372): error C2664: 'icu_56::UnicodeString &icu_56::TimeZone::getDisplayName(UBool *(__cdecl *)(void),icu_56::TimeZone::EDisplayType,const icu_56::Locale &,icu_56::UnicodeString &) const': cannot convert argument 1 from 'UBool' to 'UBool *(__cdecl *)(void)'
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(372): note: Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(380): error C2664: 'icu_56::UnicodeString &icu_56::TimeZone::getDisplayName(UBool *(__cdecl *)(void),icu_56::TimeZone::EDisplayType,const icu_56::Locale &,icu_56::UnicodeString &) const': cannot convert argument 1 from 'UBool' to 'UBool *(__cdecl *)(void)'
c:\Users\xxxxxx\bryllyg\opt\icu\56.1\pyicu_1.9.2\calendar.cpp(380): note: Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
C:\Users\xxxxxx\bryllyg\opt\python\Python-3.5.0\lib\distutils\dist.py:261: UserWarning: Unknown distribution option: 'test_suite'
warnings.warn(msg)
error: command 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe' failed with exit status
The text was updated successfully, but these errors were encountered: