summaryrefslogtreecommitdiff
path: root/external/python3
AgeCommit message (Collapse)Author
2017-02-22MSVC 14.0: Make it work with older SDK versionDavid Ostrovsky
Change-Id: I50a9e8b122250af445c2a1b3d0941d508e027318 Reviewed-on: https://gerrit.libreoffice.org/34528 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-21Fix check for non-empty UCRTVERSIONStephan Bergmann
...introduced with b862cbdd345ec57c2595629ded6a3969e1e65d56 "Support MSVC 15.0", but $(filter ...,) always expands to the empty string, and this is probably what was intended. Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862 Reviewed-on: https://gerrit.libreoffice.org/34482 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-15Support MSVC 15.0David Ostrovsky
New compiler changes quite some stuff: * Compiler detection done based on different registry key * .NET SDK detection done based on different registry key * Msbuild installation directory changed * Merge modules installation directory changed * SDK number in registry doesn't match the directory name: (registry key: 10.0.14393, directory name: 10.0.14393.0) * Compiler, include and library location directories changed * Architecture specific directory changed: x64 instead of amd64 * Compiler own include directory must be added with -I option * To force usage of SDK 10 (8.1 is selected per default) new switch WindowsTargetPlatformVersion is passed to msbuild, to avoid patching VC project files with this line: <WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion> Known issues: * Firebird is broken: http://paste.openstack.org/show/594333 Change-Id: I148d7932aff43bbbd07bd493504df974726234c2 Reviewed-on: https://gerrit.libreoffice.org/31279 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-08gbuild, python3: stop defining SOLARIS, and remove SOLARIS patchMichael Stahl
It's faster to change our code not to rely on -DSOLARIS than to wait for python developers to remove such nonsense from their public headers. Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
2017-01-17python3: upgrade to release 3.5.3Michael Stahl
- fixes some minor CVEs - drop python-vc2013.patch.1 - drop python-3.3.3-py17797.patch.1: the bug was fixed in MSVC2015 runtime so not relevant - drop python-lsan.patch.0: fixed upstream - ubsan.patch.0: drop hunks that were fixed upstream - python-3.5.0-tcltk.disable.patch: merge into msvc-disable.patch.1 Change-Id: I2aecae446539d28eaf3eb64ee67581596019335d Reviewed-on: https://gerrit.libreoffice.org/33225 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-01-17Fix patchStephan Bergmann
The original patch caused compilation of x86-ffi64.c to fail, but that failure was silently ignored by the build. Change-Id: I93a0cde041b8f9546873d6cc30c1b690da098642
2016-12-18tdf#103363: add unicodedata and import idna encoding for mailmergeJulien Nabet
Thank you Moggi for your help on how to add unicodedata module to Python! Change-Id: I071e9279d1de4748f9443ac2d624fe925288e408 Reviewed-on: https://gerrit.libreoffice.org/32140 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2016-12-16external/python3: Work around -fsanitize=alignmentStephan Bergmann
Change-Id: I26b927345594368f426ae89bfd5b645561d44c10
2016-12-16Clean up patchStephan Bergmann
Change-Id: I2aa51435d0a15e507d0bf95f98d69fa4cde00b05
2016-11-04fix build of bundled python3 with bundled zlibDavid Tardon
Change-Id: I383a04ea926187263b1d7e11c548817fa9ca3fb6
2016-10-23cond. build is already handled in Module_external.mkDavid Tardon
Change-Id: I5efe3bafc4f0b97578a75dc1f43e6c130a93bc4a
2016-09-21python3: put a RPATH into libpython3.soMichael Stahl
libpython3.so is the "ABI compatible" wrapper library around libpython3.5m.so - it is not actually used by anything in LO right now, but let's ensure it has RPATH $ORIGIN just in case. This revealed that the AIX patch in python3 accidentally changed the SONAME of libpython3.5m.so from upstream's libpython3.5m.so.1.0 on ELF platforms, because the SONAME variable was set in the shell command but read as a make variable in the next line, which is actually evaluated earlier. So rename a few files in packages to use the upstream SONAME. Change-Id: I3611f75eee62b0993b853230521a2fa41ac5cd9c
2016-09-16external/python3: Fix building against external/zlibStephan Bergmann
...whose (static) library is called "zlib" instead of just "z". (I ran into this when trying to do a 32-bit Linux build in a 64-bit environment, with only very limited 32-bit support installed in the system.) Change-Id: I9286975917ddf643a22803561677af035e66fb98 Reviewed-on: https://gerrit.libreoffice.org/28964 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-04Don't use functions introduced in 10.12 when building to run on olderTor Lillqvist
getentropy() and clock_gettime() are new in macOS Sierra (10.12). Change-Id: I93640bbf20056d925c3116df336aeaebaaffda18
2016-07-11Break gb_DEBUGINFO_FLAGS out of gb_DEBUG_CFLAGSStephan Bergmann
...in preparation of making them orthogonal Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52 Reviewed-on: https://gerrit.libreoffice.org/27056 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-07-01python3: override LINKCC properly, it needs -pthreadMichael Stahl
Build on Fedora 24 fails with "Python/thread.o: undefined reference to symbol 'pthread_key_delete@@GLIBC_2.0'" Change-Id: If23838722e1cd0220c509d25932ae0539e8da7a1
2016-07-01remove executable bit from .mk filesMichael Stahl
Change-Id: Id79898bb4f71103830ad7f74da71fbd5102e4fb5
2016-06-22uitest: we will need the python unittest moduleMarkus Mohrhard
Change-Id: Ic0589be9b3769279b201dfd314534a087c7f4309
2016-02-23Fix python packaging on MSVC 14.0, 32bitDavid Ostrovsky
Change-Id: I5604aa21981c216e992cbefae043acfd0ab07bbd Reviewed-on: https://gerrit.libreoffice.org/22626 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2016-02-22python3: drop obsolete patch, cannot build 3.5 with MSVC 2013Michael Stahl
Change-Id: I1a6b41bb95bf4edb8e81f2db54624a0892c79bc5
2016-02-22WaE vs2015 double defineNorbert Thiebaud
Change-Id: I279b5df3f9705ca266f2f4efb1e93e59cbbdabd7 Reviewed-on: https://gerrit.libreoffice.org/22603 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2016-01-07configure: hard-code /usr/bin/{sort,find} for CygwinMichael Stahl
... to avoid calling C:/Windows/system32/{sort,find}.exe, if those happen to be first in PATH. On a Windows 7 system, the other conflicts appear to be harmless, we don't use "more", "expand", "timeout", "whoami". Change-Id: Iceefeb7ee6725291b04c0eba465991bb1df96b57 Reviewed-on: https://gerrit.libreoffice.org/21175 Tested-by: Jenkins <ci@libreoffice.org> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2015-12-01Fix patch file attributesStephan Bergmann
Change-Id: I4f86aba24f2dad14f43effd6e0b291f8f58f1712
2015-10-27Fix Python 3.5 sizeof(PyGC_Head) for UBSanStephan Bergmann
...by again using 'long double' instead of 'double' to "force worst-case alignment," just like Python 3.3 used to do. This fixes -fsanitize=alignment failures like > workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:2923:10: runtime error: member access within misaligned address 0x6110007af498 for type 'CDataObject' (aka 'struct tagCDataObject'), which requires 16 byte alignment > 0x6110007af498: note: pointer points here > ff ff ff ff 01 00 00 00 00 00 00 00 98 98 17 00 90 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ^ > GenericPyCData_new workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:2923:10 > PyCFuncPtr_new workdir/UnpackedTarball/python3/Modules/_ctypes/_ctypes.c:3385:29 > type_call workdir/UnpackedTarball/python3/Objects/typeobject.c:908:11 > [...] during PythonTest_dbaccess_python. Change-Id: I8cc65823e1bc65807ec30c97a9099462e55c996d
2015-10-27Fix python3 on MSVC 14.0David Ostrovsky
Change-Id: I2882a97d0e078bd3217170e7906cd41680fbc4a4 Reviewed-on: https://gerrit.libreoffice.org/17360 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2015-10-26Adapt patchStephan Bergmann
Change-Id: I7945eed053a671ad0c755284a372d16083e596b2
2015-10-25Python3.5: Remove external dependencies: readline and lzmaDavid Ostrovsky
Change-Id: Ie5cd1c0e186920f3b34d3986aa995a5c3be9c58a
2015-10-25Bump python to 3.5David Ostrovsky
3.5 release is needed for MSVC 14.0 (aka VS 2015) support. Python 3.5 removed build toolchain support for MSVC 2013. Because we still need to support it, we duplicate the Python directory in externals and copy old patches and dispatch to this directory for MSVC 2013. Once the support for MSVC 2013 is dropped on master, this directory can be removed again. Change-Id: Idf7bc351239582f583ecbdb53c923cbdcf968089 Reviewed-on: https://gerrit.libreoffice.org/17352 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2015-10-22ubsan failure on bootstrapping crashtestingCaolán McNamara
Change-Id: Ie2b338bdd75f26953c758b64711e60b6f5ce9c83
2015-09-09externals: remove various obsolete MSVC2012 specific flagsMichael Stahl
Change-Id: I8848d042a008c21e407d9610161b5c67d2137a18
2015-06-08Allow building Python on Mac with GNU xargsKhaled Hosny
GNU xargs executes the command at least once even if the standard input is empty, unlike BSD xargs, which causes rm -r to be called with no arguments ween the find command finds nothing leading to an error. Adding -f to rm allows buikding with either implementation. Change-Id: I0df5fcb379d2a5a8b1121594ec1a82d917d80dfc Reviewed-on: https://gerrit.libreoffice.org/16116 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2015-06-02external/python3: -fsanitize=nonnull-attributeStephan Bergmann
Change-Id: Ib589b638a81bfb77fd74da8b15ae7b11cfd2b58b
2015-06-02external/python3: -fsanitize=nonnull-attributeStephan Bergmann
Change-Id: I447d1f01c24a934e643077dc271872e850b204bc
2015-05-09tdf#82968: python3: fix stdio detection on WNT harderMichael Stahl
Upgrade to the latest patch from http://bugs.python.org/issue17797 which appears to work even if you invoke from cmd.exe Change-Id: I85f1cc5ad7d8c059d972ae2a6fd2be1bb5604c2c
2015-02-23Clang -fsanitize=vptr: ensure __ubsan_vptr_type_cache in python.binStephan Bergmann
Change-Id: I7b08b7b6376db29b392243f24f6ad3ccf2ee8655
2015-02-02pyhon: add lib-dynload libs to fixinstallnames (OS X)Robert Antoni Buj i Gelonch
Change-Id: Iab76060952ae8c1b64d3ff32e5ae8f5212e016b0 Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
2015-01-13external/python3: Work around -fsanitize=alignmentStephan Bergmann
Change-Id: I33976bc96fc78dd0210d9aec6d1ec925f514c7f2
2015-01-11Fix Python build in debug mode on x86_64 platform on windowsDavid Ostrovsky
8a6c5b2f fixed Python build in release mode for x64, but missed to do the same for the debug mode. Change-Id: I9762b4089ec95fbd8af12e581fbe8577be5f802a Reviewed-on: https://gerrit.libreoffice.org/13089 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2015-01-06external/python3: Work around -fsanitize=boundsStephan Bergmann
Change-Id: I608ec429696e6a02aa528b10057d93da63544eb4
2014-11-03fdo#82430: MSVC build: disable a few more cases of SSE2 in externalsMichael Stahl
Change-Id: I8f0db23d1f9ba6b9fc3c8b64b32822ba8166428f
2014-10-16MAC_OS_X_VERSION_MIN_REQUIRED is always >= 1080 nowTor Lillqvist
Change-Id: I40d03ab9acb67ab72b9047017452f069ce88fd4b
2014-10-02fdo#82430: MSVC build: avoid using SSE2 instructions in some externalsMichael Stahl
Hopefully this should fix up the most important external libraries. Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
2014-09-19Make the patch applyTor Lillqvist
Change-Id: Ic773b86a1ebaa66a1b0ae236429276f35776deb8
2014-09-19Use correct CFBundleExecutable in the Info.plist for Python.appTor Lillqvist
The Python build machinery apparently does not use proper autoconfigury to expand this Info.plist.in file, so can't use @PYTHONFRAMEWORK@ as for the Info.plist for the framework itself, but have to hardcode LibreOfficePython. As such I am not sure that Python's way of including an app bundle inside a framework's Resources subtree is acceptable in the stricter code signing and Gatekeeper rules that soon will be in effect. Will see. Change-Id: I1ef9e7b748d41ec4b32d80e721d5fba5e7a90d18
2014-09-19Use correct CFBundleExecutable for the LibreOfficePython frameworkTor Lillqvist
It should be the basename of the framework. The Python configury already provides that as @PYTHONFRAMEWORK@. Change-Id: I116a34c3bcc8f661abe16b2b5cc1b9268ecd2780
2014-09-17Bye bye VS2010Tor Lillqvist
Change-Id: I9d16f4f0df42ae4b046bc1e4ac4fba95c4b9d785
2014-09-11For ASAN __cxa_throw interception to work, link python.bin to libstdc++Stephan Bergmann
...where the intercepted __cxa_throw is found, as otherwise PythonTest_sw_python fails with AddressSanitizer CHECK failed: projects/compiler-rt/lib/asan/asan_interceptors.cc:293 "((IndirectExternCall(__interception::real___cxa_throw))) != (0)" (0x0, 0x0) #0 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) projects/compiler-rt/lib/asan/asan_rtl.cc:70:3 #1 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:76:5 #2 0x48c3ac in __cxa_throw projects/compiler-rt/lib/asan/asan_interceptors.cc:293:3 #3 0x7f67faec0ef5 in pyuno::createClass(rtl::OUString const&, pyuno::Runtime const&) pyuno/source/module/pyuno_except.cxx:92:9 ... Change-Id: I0cb364eacab49644b426fb62f49bf9d7c8b5090c
2014-09-09Make the "Mac-like" or "canonical" app bundle structure always used on OS XTor Lillqvist
In other words, only executable files go in the MacOS folder. Dynamic libraries and bundled frameworks (i.e., LibreOfficePython), and nothing else, go in the Frameworks folder, and all other files go in the Resources folder. Especially, note that Java class files and rc (.ini) files also go in Resources. Such an app bundle structure is what Apple strongly suggests one should use, and it has been hinted that future versions of code signing and/or Gatekeeper will require such a structure. There is still some ugliness thanks to traces of the historical separation of URE from "the office". Like there are two separate "unorc" files, one for URE, one for the LibreOffice application. IMHO, this should be cleaned up, but is probably controversial. (Eek! I now see there are actually *three* unorc files in the app bundle. Not intentional. Need to fix that later.) Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
2014-08-09VS2013: Override ToolsVersion settingThomas Arnhold
Otherwise those external projects will fail, because with only VS2013 installed there is no ToolsVersion 4.0 (which is set inside the VC projects files). http://msdn.microsoft.com/en-us/library/bb383985.aspx Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd