summaryrefslogtreecommitdiff
path: root/external/python3
AgeCommit message (Collapse)Author
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
2014-07-29Make python3 build with VS2013Tor Lillqvist
This time use a patch to mangle the project files a bit so that msbuild likes them. Change-Id: I1293f4a92164ec6431b96c39f118cbdedbe5fe32
2014-07-14ExternalProject_python3.mk: MACOSXrbuj
To build a universal binary in Mac OS X 10.6+ with an Intel processor, it is better to set --with-universal-archs=intel, remember that Rosetta is not installed by default in Mac OS X v10.6 and it is neither included nor supported in Mac OS X v10.7 or later. If we don't use --with-universal-archs then the configure.ac sets the architectures: ... UNIVERSAL_ARCHS="32-bit" if test "`uname -s`" = "Darwin" then if test -n "${UNIVERSALSDK}" then if test -z "`/usr/bin/file "${UNIVERSALSDK}/usr/lib/libSystem.dylib" | grep ppc`" then UNIVERSAL_ARCHS="intel" fi fi fi ... In Snow Leopard (Mac OS 10.6): /usr/bin/file /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 4 architectures /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64 /usr/bin/file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib: Mach-O universal binary with 3 architectures /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc If x86_64 (for OS X 10.8+) or PPC (for OS X 10.5) is only desired then a universal binary is not useful and we don't have to use --enable-universalsdk=${UNIVERSALSDK}. Change-Id: Ib0578cfdb912fed5a803df3d2e04d2b037cfe13f Reviewed-on: https://gerrit.libreoffice.org/10249 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-07-11avoid -arch for bundled OpenSSL, Python3, and nss/nspr on OSX@PowerPCDouglas Mencken
this fixes gcc: error: unrecognized command line option '-arch' The '-arch' option is part of Apple's extensions to GCC, and it is uncompatible with "vanilla" GCC from FSF. Also, we're not building "universal binaries". Change-Id: I44e7c72bbb1dd4be5ac9cdbc4f210aaccea513b4 Reviewed-on: https://gerrit.libreoffice.org/10117 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2014-07-11VS2013: Adjust python3 to 12.0 vcproj versionDavid Ostrovsky
Change-Id: Ic4566e8a199d3f31d6d4cb2d3fd41ad7b762c02a Reviewed-on: https://gerrit.libreoffice.org/10162 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2014-07-08VS 2013 has round()Tor Lillqvist
Change-Id: I1cc91bccd288543162b1169ce5621a91a5d4f991
2014-06-09python3: stop symlinking directories on WNTMichael Stahl
Change-Id: I281d3dd66a8db8da44cce60bade4a0ee7d1df763
2014-05-26externals: do not use "v110_xp" when building with MSVC 2012 and SDK 8.0Michael Stahl
Change-Id: I40bc9e4c31e270f29cc145b5d2f3544cad586bf7
2014-05-24fdo#77891 unconditionally disable console streams for WinXPChristian Lohmaier
as the functions to check for a valid filehandle don't work according to the documentation. Python in LO-Context is run from GUI anyway, and thus won't have those hooked up. Change-Id: I8bc048463b0dc1a25c1b6ba7422623dda110eddc
2014-05-23external/python3: Fix memory leak in configure check codeStephan Bergmann
...that LeakSanitizer would complain about, causing the check to erroneously fail. Change-Id: Ieaef38576afd6196d38f395d48fd1bc92b22ddb6
2014-05-22use $(gb_AWK) instead of awkChristian Lohmaier
Change-Id: Ia00d7e52de5edfce09c3a0a8aa4390e3e1582a01
2014-05-21upgrade to python-3.3.5Thomas Arnhold
- remove now obselete patches, which were applied upstream. - Hack to get MacOS to build Change-Id: Id68e78e411efc92a46ea9e180f09c390fe5acb4a Reviewed-on: https://gerrit.libreoffice.org/9311 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
2014-05-19fdo#77891 fix python crash when in GUI mode, target WinXP with VS2012Christian Lohmaier
VS2012 did change return value of fileno function, this results in a crash when run in GUI mode (but not when launching from a shell), as python tries to access the nonexisting stdin/stdout/stderr Also explicitly target Windows XP Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
2014-05-08Make external/python3 play well with -fsanitize=addressStephan Bergmann
Change-Id: I72a9ec9569bcd74e212ad98456a76869ac213221
2014-04-15python3: remove obsolete MSVC2008 patchesMichael Stahl
Change-Id: Ie514017dc186fea4c3f2699e92bfe46706eb6413
2014-03-11normalize values of MINGW_SHARED_GCCLIB/MINGW_SHARED_GXXLIBMichael Stahl
Change-Id: I4f4cecd95f87b9d37fa1b1a270cf554d7707aaa2
2014-02-27normalize values of CROSS_COMPILINGMichael Stahl
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
2014-02-22external: Use gb_LTOFLAGS only in LDFLAGS to fix building.Matúš Kukan
liborcus was not building for me with -flto in CFLAGS, I would have to fix ar somehow. -flto in LDFLAGS is just to fix the build if the external library does use another library built by us with -flto: does happen for liborcus and python3. It's not like we would use -flto for external libraries consistently anyway, the only exception is icu: no idea why we build with -flto there. Change-Id: Ia54d619674b8999ce5e4b920ba77b1587c9cf48d
2014-02-21Use gb_LTOFLAGS for python3 too.Matúš Kukan
Change-Id: Ida2dee3b66dd7fbc7942d47a13ce38dda82db866
2014-02-12normalize values of SYSTEM_PYTHON, SYSTEM_MYSQL_CPPCONNMichael Stahl
Change-Id: I8932febdd39c35f23fb3a89703b69e25302f5678
2014-02-12normalize values of SYSTEM_CLUCENE, SYSTEM_EXPAT, SYSTEM_JPEGMichael Stahl
Change-Id: I343dae79b01e1369722c7bbd1ab2c36e2bfa96ac
2014-02-12fdo#74825: fix missing lcms2/libxslt/curl in installation setsMichael Stahl
The assumption that all configure variables had been normalized to TRUE/<empty> turned out not to hold; convert a bit more in that direction. (regression from 4af38b099c741c3676aefeb20c515913aaeed666) Change-Id: I2127c515e8a833a07c9b26ed9d693ce5a1853fe4
2014-01-15fdo#70796 fix quoted printable encoding bug in internal PythonAndras Timar
Change-Id: I4e5563c47df83c50df75ccf330fbd38ec6da9170
2014-01-06fdo#73087: python3: upgrade to version 3.3.3Michael Stahl
- drop obsolete/upstreamed patches: python-3.3.0-ffi-clang.patch.1 python-3.3.0-15833.patch.1 one hunk of python-3.3.0-aix.patch.1 in fficonfig.py.in Change-Id: I12f0f78a172067986b63455847015ea2430a084c Reviewed-on: https://gerrit.libreoffice.org/7278 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2013-11-04fdo#70393: move python3 to a subdir of externalKhaled Hosny
Change-Id: Ic5796f096255d2d84e39415324e8a2e06bcf09c9 Reviewed-on: https://gerrit.libreoffice.org/6550 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
generated by cgit (git 2.34.1) at 2024-12-25 13:18:49 +0000