The patch is in the attachment.
The timezone part seems pretty non-controversial. The _PyVerify_fd
thing seems more scary, but I basically copied that part out of
python3, so I assume they know what they are doing. With this I can
compile and run the python and it appears to be working. The real test
will be when I try to run the lldb test suite with it, but I didn't
set that up yet.
pl
On 4 February 2016 at 16:06, Zachary Turner <ztur...@google.com> wrote:
> Out of curiosity, did you guys get Python 2.7 building with VS2015? How did
> you solve the compiler error? (I had a few ideas myself for how to fix it,
> but I wasn't sure of the implications)
>
> On Thu, Feb 4, 2016 at 8:01 AM Pavel Labath <lab...@google.com> wrote:
>>
>> Hi all.
>>
>> we (android lldb team) are starting to transition to VS2015 as well.
>> For now, the plan is to stick to python 2.7, but if we encounter
>> problems there, the backup plan is to go to python 3 as well. Until
>> then (I estimate that will take 1--2 weeks) our buildbot
>> <http://lab.llvm.org:8011/builders/lldb-windows7-android> will
>> continue building 2.7+2013 and we will be making sure it works, so
>> please don't check in any VS2013 incompatible code (yet).
>>
>> Ted: If you can't switch to the 3+2015 combination (which I *do*
>> recommend you try), maybe you can go half-way and switch to 2.7+2015
>> (I can show you how to build python 2.7 with VS2015). If you stick
>> with 2.7+2013 combo, it will soon be up to you to chase anyone who
>> adds 2013-breaking changes...
>>
>> pl
>>
>>
>> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
>> <lldb-dev@lists.llvm.org> wrote:
>> > No, it turned red Friday night/Saturday morning.
>> >
>> >
>> >
>> > Last good build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>> >
>> >
>> >
>> > First bad build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>> >
>> >
>> >
>> > It went red because of the change to VS2015/Python 3.5.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 5:28 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > BTW, I expect that your buildbot has been experiencing the problems with
>> > the
>> > x86 / x64 toolchain for quite some time, because it's not really
>> > relevant to
>> > how much memory your machine has, but just that it was using an x86
>> > toolchain at all. Has it been red for a long time?
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner <ztur...@google.com>
>> > wrote:
>> >
>> > You may have to make some changes to the zorg scripts to keep that
>> > working.
>> > I didn't realize there were any other bots building LLDB, so I made some
>> > changes that will default everything to VS2015 and Py3.
>> >
>> >
>> >
>> > BTW, is your builder doing a debug build or a release build? When doing
>> > a
>> > debug build clang now requires more memory than can fit in a 4GB address
>> > space to link, so using an x86 toolchain won't work anymore. I forced a
>> > change to use the amd64_x86 toolchain, but this won't work unless the
>> > version of python used by buildbot is a 64-bit Python distro (because
>> > Python.exe is what ultimately calls vcvarsall and cmake and it inherits
>> > the
>> > environment of the parent).
>> >
>> >
>> >
>> > So I think you will need to do all this as well.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
>> > <ted.woodw...@codeaurora.org>
>> > wrote:
>> >
>> > Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 3:43 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > It's Server 2008 R2 technically, which is the server version of Win 7
>> > (same
>> > API set, same OS features, etc). So yea, I'm pretty confident that test
>> > coverage is going to be 100% the same across both. It's just a matter
>> > of if
>> > you want to have something that you maintain / have control over, or if
>> > you
>> > want to test something in a different way than what we're testing.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward
>> > <ted.woodw...@codeaurora.org>
>> > wrote:
>> >
>> > Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 2:48 PM
>> > To: Ted Woodward; LLDB
>> >
>> >
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > If I remember correctly your bot isn't actually doing anything
>> > differently
>> > than my bot
>> > [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015].
>> > If you want you could just remove your bot. If you want to keep it,
>> > then
>> > yea getting it on VS2015 and Python 3 would be the best idea.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
>> > <lldb-dev@lists.llvm.org> wrote:
>> >
>> > It looks like our bot,
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc
>> > , has tried to update to Python 3.5 and MSVC 2015, but it can’t find
>> > python
>> > or VC. I’ll talk to our buildmiester about it.
>> >
>> >
>> >
>> > Should we run this guy with 2013/py2.7 or 2015/py3.5?
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
>> > Zachary
>> > Turner via lldb-dev
>> > Sent: Tuesday, February 02, 2016 1:55 PM
>> > To: Tamas Berghammer; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 11:42 AM Tamas Berghammer
>> > <tbergham...@google.com>
>> > wrote:
>> >
>> > Hi Zachary,
>> >
>> >
>> >
>> > We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows
>> > for
>> > Android Studio and we also have a buildbot what is testing this
>> > configuration (without sending e-mail at the moment) here:
>> > http://lab.llvm.org:8011/builders/lldb-windows7-android
>> >
>> >
>> >
>> > We are in the discussion to decide what is our plan for going forward
>> > both
>> > in terms of Visual Studio version and Python version and I expect that
>> > we
>> > will make a decision this week. Until then please don't remove any hack
>> > we
>> > have in the code because of MSVC 2013 (e.g. alias template workarounds)
>> > and
>> > if adding new code then please try not to break MSVC 2013. I will send
>> > out
>> > an update about our decision hopefully at the end of this week.
>> >
>> > Yea I mentioned already that I'm not planning on removing anything
>> > related
>> > to MSVC 2013, just that I'm personally not supporting it. Which means
>> > that
>> > if anyone asks for help, or wants to make it work, or if it breaks
>> > accidentally, they're on their own :) I don't even have MSVC 2013
>> > installed
>> > on my machine anymore, so I can't fix any MSVC 2013 specific issues that
>> > arise.
>> >
>> >
>> >
>> > Of course if someone else comes along and wants to help, I have no
>> > problem
>> > with that, but due to the difficulty of dealing with incompatibility
>> > between
>> > Python 2 and MSVC 2015, it's just going to be up to someone else to
>> > continue
>> > making that work if they need it.
>> >
>> >
>> >
>> >
>> >
>> > You mentioned that LLVM plan to bump the minimum version of MSVC to
>> > 2015. Do
>> > you have any link to the place where they discussed it or do you know
>> > anything about the schedule?
>> >
>> >
>> >
>> > As far as I know the discussion hasn't started yet, but historically
>> > LLVM
>> > has always been pretty consistent about bumping the required MSVC
>> > version
>> > every 12-18 months. I know some of the Windows people on the LLVM side
>> > are
>> > already "unoficially" using MSVC 2015 on a regular basis, and that's
>> > usually
>> > a sign that people are getting an early start to see what kind of issues
>> > might be encountered by the general public when bumping the required
>> > version.
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
diff -aur DD13/python/Python-2.7.10/Include/fileobject.h D13/python/Python-2.7.10/Include/fileobject.h
--- DD13/python/Python-2.7.10/Include/fileobject.h 2015-05-23 09:08:59.000000000 -0700
+++ D13/python/Python-2.7.10/Include/fileobject.h 2016-02-01 07:44:58.584039000 -0800
@@ -70,16 +70,13 @@
*/
int _PyFile_SanitizeMode(char *mode);
-#if defined _MSC_VER && _MSC_VER >= 1400
+#if defined _MSC_VER && _MSC_VER < 1900
/* A routine to check if a file descriptor is valid on Windows. Returns 0
* and sets errno to EBADF if it isn't. This is to avoid Assertions
* from various functions in the Windows CRT beginning with
* Visual Studio 2005
*/
int _PyVerify_fd(int fd);
-#elif defined _MSC_VER && _MSC_VER >= 1200
-/* fdopen doesn't set errno EBADF and crashes for large fd on debug build */
-#define _PyVerify_fd(fd) (_get_osfhandle(fd) >= 0)
#else
#define _PyVerify_fd(A) (1) /* dummy */
#endif
diff -aur DD13/python/Python-2.7.10/Modules/posixmodule.c D13/python/Python-2.7.10/Modules/posixmodule.c
--- DD13/python/Python-2.7.10/Modules/posixmodule.c 2015-05-23 09:09:20.000000000 -0700
+++ D13/python/Python-2.7.10/Modules/posixmodule.c 2016-02-01 07:45:21.684348800 -0800
@@ -529,7 +529,7 @@
#endif
-#if defined _MSC_VER && _MSC_VER >= 1400
+#if defined _MSC_VER && _MSC_VER < 1900
/* Microsoft CRT in VS2005 and higher will verify that a filehandle is
* valid and raise an assertion if it isn't.
* Normally, an invalid fd is likely to be a C program error and therefore
@@ -619,7 +619,7 @@
}
#else
/* dummy version. _PyVerify_fd() is already defined in fileobject.h */
-#define _PyVerify_fd_dup2(A, B) (1)
+#define _PyVerify_fd_dup2(fd1, fd2) (_PyVerify_fd(fd1) && (fd2) >= 0)
#endif
/* Return a dictionary corresponding to the POSIX environment table */
diff -aur DD13/python/Python-2.7.10/Modules/timemodule.c D13/python/Python-2.7.10/Modules/timemodule.c
--- DD13/python/Python-2.7.10/Modules/timemodule.c 2015-05-23 09:09:21.000000000 -0700
+++ D13/python/Python-2.7.10/Modules/timemodule.c 2016-02-01 07:08:57.757978000 -0800
@@ -710,7 +710,7 @@
#ifdef PYOS_OS2
PyModule_AddIntConstant(m, "timezone", _timezone);
#else /* !PYOS_OS2 */
- PyModule_AddIntConstant(m, "timezone", timezone);
+ PyModule_AddIntConstant(m, "timezone", _timezone);
#endif /* PYOS_OS2 */
#ifdef HAVE_ALTZONE
PyModule_AddIntConstant(m, "altzone", altzone);
@@ -718,12 +718,12 @@
#ifdef PYOS_OS2
PyModule_AddIntConstant(m, "altzone", _timezone-3600);
#else /* !PYOS_OS2 */
- PyModule_AddIntConstant(m, "altzone", timezone-3600);
+ PyModule_AddIntConstant(m, "altzone", _timezone-3600);
#endif /* PYOS_OS2 */
#endif
- PyModule_AddIntConstant(m, "daylight", daylight);
+ PyModule_AddIntConstant(m, "daylight", _daylight);
PyModule_AddObject(m, "tzname",
- Py_BuildValue("(zz)", tzname[0], tzname[1]));
+ Py_BuildValue("(zz)", _tzname[0], _tzname[1]));
#else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/
#ifdef HAVE_STRUCT_TM_TM_ZONE
{
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
